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

Question

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

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

Спасибо

Answer 1

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

Answer 2

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

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

Answer 3

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

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

классы, которые реализуют исходный интерфейс, уже реализуют его полностью.

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

public class SomeProvider : IAmAHugeInterface { … }

с помощью:

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

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

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

Answer 4

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

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

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

public class BigNastyClass : IBigNastyInterface
{
}

Идет к:

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

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

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

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

public class DriverProvider : IBigNastyInterface
{
}

Кому:

public class DriverProvider : IDriverProvider
{
}

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