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

Question

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

Answer 1

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

Answer 2

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

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

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

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

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 или реализовать Посредник шаблон, обеспечивающий слабую связь между этими тремя классами и выполняющий работу.Держать coupling расставаться с responsibility.