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

在以下video中，作者采用现有类并将单责任原则分配给它。他需要一个具有访问数据，格式化和打印报告工作的打印类。他将每种方法分解到自己的类中，因此他创建了一个DataAccess类来处理数据访问，他创建了一个ReportFormatter类来处理报表的格式，并且他创建了一个ReportPrinter类来处理报表的打印。最初的Report类留下了一个方法Print（），它调用ReportPrinter的类方法Print。 DataAccess和ReportFormatter似乎有责任，但ReportPrinter依赖于DataAcess和ReportFormatter，所以这不会破坏SRP还是我误解了它？在以下示例中对单责任原则感到困惑

来源

2009-08-01 Xaisoft

单一责任原则表明给定的班级应该有单一的责任（或“改变的理由”）。它本身并不表明如何满足这一责任。这样做可以并且经常需要多个其他类的合作作为合作者。

来源

2009-08-01 00:45:50

SRP没有解决依赖关系。将课程分成单一责任类将有助于稍后打破这些依赖关系。 SRP解决了两个一起提到的两个原则之一：内聚和耦合。 SRP关于高内聚性，并且依赖性可以指示高耦合。好的设计有很高的凝聚力和低耦合度。有时候这两个原则可能不一致。

来源

2009-08-01 00:33:16 Robert

我认为单个类与整个实现有更高的耦合比四个单独的类。单个类与数据访问，格式化和打印的实现相结合，而四个独立的类仅与每个类的定义耦合。仅仅因为有更多的班级并不意味着有更高的联系。 – 2009-08-05 22:58:24

没有看视频，这听起来像一个合理的设计。因为处理数据访问的方法没有出现在ReportPrinter类中，所以SRP没有被破坏，只有“我可以调用某些东西来获取我想要的数据”的概念。

您可以进一步推动它，并且有一个协调器类只负责协调数据访问类，格式化程序类和打印机类的活动。您也可以用不同的方式排列对象，例如让协调器将数据发送给格式器，格式器将数据发送给打印机，协调器不会（直接）了解打印机。

有些事情需要了解协调狭隘集中的对象的努力。这成为他们的责任。只要你不知道或在意他们如何做就可以知道其他对象会做什么的想法或概念。将接口视为“责任接缝”是一个好的开始。

如果您将对象看作是将数据传递给对方，而不是“做”事情，那么它也会很有帮助。因此，ReportFormatter返回（或转发）表示格式化报表的新对象，而不是（在概念上）在现有报表上执行对象。

来源

2009-08-01 00:43:30 kyoryu

不，它不会破坏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。

来源

2016-02-07 05:53:13

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

回答

相关问题