Запутался в принципе единой ответственности в следующем примере

Question

В следующем видео автор берет существующий класс и присваивает ему принцип единой ответственности. Он берет класс печати, который имеет доступ к данным, форматированию и печати отчета. Он разбивает каждый метод на собственный класс, поэтому он создает класс DataAccess для обработки доступа к данным, создает класс ReportFormatter для обработки форматирования отчета и создает класс ReportPrinter для обработки печати отчета. Исходный класс Report затем остается с одним методом Print (), который вызывает метод класса ReportPrinter Print. DataAccess и ReportFormatter, по-видимому, несут ответственность, но ReportPrinter полагается на DataAcess и ReportFormatter, так что это не нарушает SRP или я неправильно понимаю?

Answer 1

Без просмотра видео звучит как разумный дизайн. SRP не нарушен, так как методы, относящиеся к доступу к данным, не отображаются в классе ReportPrinter, только концепция, что «я могу вызвать что-то для получения нужных данных».

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

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

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

Answer 2

Принцип единой ответственности указывает на то, что данный класс должен нести одну ответственность (или «повод для изменения»). Само по себе это не указывает на то, как эта ответственность должна быть выполнена. Это может и часто требует сотрудничества нескольких других классов в качестве соавторов.

Answer 3

SRP не решает зависимости. Разбиение класса на классы с одной ответственностью облегчит разрушение этих зависимостей позже. SRP рассматривает один из двух принципов, упомянутых вместе: сплоченность и сцепление. SRP о высокой когезии, и зависимости могут указывать на высокую связь. Хорошие конструкции имеют высокую когезию и низкое сцепление. Иногда эти два принципа могут противоречить друг другу.

Answer 4

Нет. Не нарушает SRP.

Предположим, что

DataAccess implements IDataAccess    

ReportFormatter  implements IReportFormatter 

ReportPrinter implements IReportPrinter 

Несмотря на то, что ReportPrinter relies on DataAccess and ReportFormatter, любое изменение в контракте IDataAccess or IReportFormatter должно быть реализовано DataAccess and ReportFormatter соответственно. ReportPrinter не беспокоится об изменении ответственности в этих классах.

Вы можете использовать Composition или реализовать шаблон Mediator , чтобы обеспечить слабую связь между этими тремя классами и выполнить работу. Держите coupling часть подальше от responsibility.