В следующем видео автор берет существующий класс и назначает принцип единой ответственности для Это. Он берет класс печати, который выполняет работу по доступу к данным, форматированию и печати отчета. Он разбивает каждый метод на отдельный класс, поэтому он создает класс DataAccess для обработки доступа к данным, он создает класс ReportFormatter для обработки форматирования отчета и создает класс ReportPrinter для обработки печати отчета. В исходном классе Report остается один метод Print (), который вызывает метод класса ReportPrinter Print. Похоже, что DataAccess и ReportFormatter несут ответственность, но ReportPrinter полагается на DataAcess и ReportFormatter, так что это не нарушает SRP, или я неправильно это понимаю?
Не понимаете принцип единой ответственности в следующем примере
Ответы (4)
Принцип единой ответственности указывает, что данный класс должен иметь единственную ответственность (или «причину для изменения»). Само по себе это не указывает на то, как эта ответственность должна быть удовлетворена. Для этого может потребоваться и часто требуется сотрудничество нескольких других классов в качестве соавторов.
person
Brandon E Taylor
schedule
01.08.2009
Без просмотра видео это звучит как разумный замысел. SRP не нарушен, поскольку методы, имеющие дело с доступом к данным, не отображаются в классе ReportPrinter, а только концепция «Я могу вызвать что-то, чтобы получить данные, которые мне нужны».
Вы могли бы продвинуться немного дальше и иметь класс координатора, отвечающий только за координацию действий класса доступа к данным, класса форматировщика и класса принтера. Вы также можете расположить объекты по-разному, например, если координатор отправляет данные в форматтер, который отправляет их на принтер, а координатор (напрямую) не знает о принтере.
Что-то нужно знать о координации усилий узконаправленных объектов. Это становится их ответственностью. Это нормально знать идею или концепцию того, что будут делать другие объекты, если вы не знаете или не заботитесь, как они это делают. Думать об интерфейсах как об «пластах ответственности» - хорошее начало.
Это также может быть полезно, если вы думаете об объектах как об объектах, передающих данные друг другу, а не о «делающих» действиях. Таким образом, ReportFormatter возвращает (или пересылает) новый объект, представляющий отформатированный отчет, а не (концептуально) выполняет объекты в существующем отчете.
person
kyoryu
schedule
01.08.2009
SRP не учитывает зависимости. Разделение класса на классы с единственной ответственностью облегчит разбиение этих зависимостей позже. SRP обращается к одному из двух упомянутых вместе принципов: сплоченности и сцепления. SRP говорит о высокой степени связанности, а зависимости могут указывать на высокую степень связи. Хорошие конструкции имеют высокое сцепление и низкое сцепление. Иногда эти два принципа могут противоречить друг другу.
person
Robert
schedule
01.08.2009
Я бы сказал, что один класс со всей реализацией имеет более сильную связь, чем четыре отдельных класса. Единый класс связан с реализацией доступа к данным, форматирования и печати, в то время как четыре отдельных класса связаны только с определениями каждого класса. То, что классов больше, не означает, что связь выше.
- person Stefan Moser; 06.08.2009
Нет. Это не нарушает 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.
person
Ravindra babu
schedule
07.02.2016
