在以下示例中对单一责任原则感到困惑

Question

在下面的video中，作者采用现有的类并为其分配单一责任原则。他选择了一个打印类，它具有访问数据，格式化和打印报告的功能。他将每个方法分解为自己的类，因此他创建了一个DataAccess类来处理数据访问，他创建了一个ReportFormatter类来处理Report的格式，并创建了一个ReportPrinter类来处理Report的打印。然后，原始的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。