ответственности, можно прийти к потоку данных, изображенному на рис. 8.1. Некоторая процедура анализирует финансовые данные и производит данные для отчета, которые затем форматируются двумя процедурами формирования отчетов.
Рис. 8.1. Результат применения принципа единственной ответственности
Самое важное, что нужно понять, – в данном примере в создание отчета вовлечены две отдельные ответственности: вычисление данных для отчета и представление этих данных в форме веб-отчета или распечатанного отчета.
Сделав такое разделение, мы должны организовать зависимости в исходном коде так, чтобы изменения в одной из ответственностей не вызывали необходимости изменений в другой. Кроме того, новая организация должна гарантировать возможность расширения поведения без отмены изменений.
Этого можно добиться, выделив процессы в классы, а классы в компоненты, ограниченные двойными линиями на рис. 8.2. Компонент в левом верхнем углу на этом рисунке – контроллер. В правом верхнем углу – интерактор, или посредник. В правом нижнем углу – база данных. Наконец, в левом нижнем углу изображены четыре компонента – презентаторы и представления.
Классы, отмеченные символами <I>, – это интерфейсы; отмеченные символами <DS> – это структуры данных (data structures). Простые стрелки соответствуют отношениям использования. Стрелки с треугольным наконечником соответствуют отношениям реализации или наследования.
Первое, на что следует обратить внимание, – все зависимости определены на уровне исходного кода. Стрелка, направленная от класса A к классу B, означает, что в исходном коде класса A упоминается имя класса B, но в коде класса B не упоминается имя класса A. Так, на рис. 8.2 диспетчер финансовых данных знает о существовании шлюза через отношение реализации, а шлюз финансовых данных ничего не знает о диспетчере.
Рис. 8.2. Выделение процессов в классы и выделение классов в компоненты
Также важно отметить, что каждая двойная линия пересекается только в одном направлении. Это означает, что все отношения компонентов однонаправленны, как показано на графе компонентов (рис. 8.3). Эти стрелки указывают на компоненты, которые мы стремимся защитить от изменения.
Позволю себе повторить еще раз: если компонент A требуется защитить от изменений в компоненте B, компонент B должен зависеть от компонента A.
Нам нужно защитить контроллер от изменений в презентаторах. Нам нужно защитить презентаторы от изменений в представлениях. Нам нужно защитить интерактор от изменений в… во всех остальных компонентах.
Интерактор находится в позиции, лучше соответствующей принципу открытости/закрытости. Изменения в базе данных, или в контроллере, или в презентаторах, или в представлениях не должны влиять на интерактор.
Рис. 8.3. Отношения компонентов однонаправленны
Почему интерактор должен придерживаться такой привилегированной