Наследование интерфейса для разделения объектов бога?

Question

Я работаю над довольно крупным продуктом. Он находился в разработке, так как.Net 1.0 все еще находился в стадии разработки, поэтому в нем много плохого качества кода, и он не был написан с учетом модульных тестов. Сейчас мы пытаемся улучшить качество и внедрить тесты для каждой функции и исправления ошибки. Одна из самых больших проблем, с которыми мы сталкиваемся сейчас, - это зависимость от ада и бога. В частности, есть один божий объект: Session, По сути, все, что связано с текущим сеансом программы, находится в этом объекте. Есть также несколько других объектов бога.

В любом случае, мы сделали этот объект бога "насмешливым", используя Resharper для извлечения интерфейса из них. Тем не менее, это все еще затрудняет тестирование, потому что большую часть времени вам приходится смотреть на код, который вы пишете, чтобы выяснить, что на самом деле нужно макетировать из 100 различных методов и свойств.

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

Поскольку у меня есть интерфейс (и почти весь код был переработан для использования интерфейса), у меня была интересная идея. Что делать, если я сделал ISession интерфейс наследуется от других интерфейсов.

Например, если бы у нас было что-то вроде этого:

interface IBar
{
  string Baz{get;set;}
}

interface IFoo
{
  string Biz{get;set;}
}

interface ISession: IFoo, IBar
{
}

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

И, в конце концов, я вижу, что это, вероятно, облегчает в конечном итоге разбить фактический интерфейс / объект ISession и Session god

Теперь к тебе. Является ли это хорошим способом проверки против этих божественных объектов и, в конечном итоге, их разрушения? Это документированный подход и / или шаблон проектирования? Ты когда-нибудь делал что-нибудь подобное?

Answer 1

С моей точки зрения это хороший и правильный подход. Позже вы можете добавить более конкретные экземпляры службы как IFoo/IBar скорее, чем ISessionЯ бы сказал, что это хороший промежуточный шаг перед дальнейшим рефакторингом для извлечения классов из класса богов во многие конкретные службы.

Некоторые плюсы, которые я вижу:

Первый этап: извлечение интерфейсов

• Тип супер (бога) абстрагируется интерфейсами
• Код становится менее связанным, поскольку полагается на однофункциональные ответственные интерфейсы (сервисы)
• У вас есть основания двигаться дальше и разделить класс God на множество сервисов без необходимости масштабного рефакторинга. Everythign уже полагается на интерфейсы API.

Второй этап: разделить класс бога на множество небольших служб, помня принцип единой ответственности.

Третий этап: структурировать существующие модульные тесты, чтобы тесты группировались по типу службы, а не по всему классу богов.