Нужны предложения относительно рефакторинга интерфейса

Question

Я унаследовал проект, который объявлен неловко большим интерфейсом (позволяет называть его IDataProvider). Существуют методы для всех аспектов приложения, сгруппированных внутри файла. Не то, чтобы это огромная проблема, но я бы предпочел, чтобы они разделились на более мелкие файлы с описательным именем. Чтобы реорганизовать интерфейс и разбить его на нескольких интерфейсах (скажем, IVehicleProvider, IDriverProvider и т. Д.), Потребуется массивный рефакторинг кода, потому что существует много классов, реализующих интерфейс. Я думаю о двух других способах сортировки: 1) Создайте несколько файлов для каждого отдельного аспекта приложения и сделайте интерфейс частично или 2) Создайте несколько интерфейсов, таких как IVehicleProvider, IDriverProvider и унаследовайтесь от интерфейса IDataProvider.

Какое из перечисленных выше вы предпочли бы и почему? Или, если вы можете думать лучше, расскажите.

Благодаря

Answer 1

This book предполагает, что интерфейсы принадлежат не поставщику, а скорее клиент интерфейса. То есть вы должны определять их на основе своих пользователей, а не классов, которые их реализуют. Применительно к вашей ситуации пользователи IDataProvider каждый используют (возможно) только малую часть функциональности этого большого интерфейса. Выберите одного из этих клиентов. Извлеките поднабор функциональности, который он использует в новый интерфейс, и удалите эту функциональность из IDataProvider (но если вы хотите, чтобы IDataProvider расширил ваш новый интерфейс, чтобы сохранить существующее поведение, не стесняйтесь). Повторяйте до конца - а затем избавьтесь от IDataProvider.

Answer 2

Верно ли, что большинство, если не все классы, которые реализуют этот интерфейс, один большой есть много методов, которые либо вообще ничего не делать или бросать исключения?

Если это не так, и у вас есть большие большие классы с множеством различных проблем, включенных в него, то вы будете испытывать болезненный рефакторинг, но я думаю, что обработка этого рефакторинга теперь - лучший подход - альтернативы вы предлагаете просто подтолкнуть вас к разным плохим ситуациям, откладывая боль за небольшую выгоду.

Единственное, что можно сделать, это применить несколько интерфейсов к одному классу (в большинстве языков), так что вы можете просто создать новые интерфейсы и заменить один большой интерфейс с несколькими меньшими:

public class BigNastyClass : IBigNastyInterface 
{ 
} 

Goes чтобы:

public class BigNastyClass : ISmallerInferface1, ISmallerInterface2 ... 
{ 
} 

Если вы не имеете огромные классы, которые реализуют весь интерфейс, я бы решить эту проблему на классе по классовой основе. Для каждого класса, который реализует этот большой интерфейс, вводится новый конкретный интерфейс только для этого класса.

Таким образом вам нужно всего лишь реорганизовать базу кода по одному классу за раз.

DriverProvider, например, будет идти от:

public class DriverProvider : IBigNastyInterface 
{ 
} 

To:

public class DriverProvider : IDriverProvider 
{ 
} 

Теперь вы просто удалить все неиспользуемые методы, которые не делают ничего, кроме просто удовлетворяющий большой интерфейс, и исправить какие методы должны быть переданы в DriverProvider.

Answer 3

Трудно ответить без каких-либо тегов или информации, сообщающих нам технологию или технологии, в которых вы работаете.

Предполагая, что исходный рефакторинг должен быть минимальным.

Классы, реализующие оригинальный интерфейс, уже реализуют его целиком.

После создания меньших интерфейсов, вы просто изменить:

public class SomeProvider : IAmAHugeInterface { … } 

с:

public class SomeProvider : IProvideA, IProvideB, IProvideC, IProvideD { … } 

... и ваш код работает именно так, как это делали раньше, до тех пор, пока вы не добавили или удалили всех участников из того, что было там для начала.

Оттуда вы можете уничтожить классы по мере необходимости или по возможности и удалить дополнительные методы и интерфейсы из декларации.

Answer 4

Я бы сделал последний. Сделайте индивидуальные, меньшие интерфейсы, а затем сделайте «большой» интерфейс агрегацией из них.

После этого вы можете реорганизовать большой интерфейс у своих потребителей, если это применимо.