对以下示例中的单一职责原则感到困惑
在下面的视频中，作者采用了一个现有的类，并将单一职责原则分配给它。 他参加了打印课程，其任务是访问数据、格式化和打印报告。 他将每个方法分解为自己的类，因此他创建了一个 DataAccess 类来处理数据访问，创建了一个 ReportFormatter 类来处理报表的格式设置，并创建了一个 ReportPrinter 类来处理报表的打印。 原始的 Report 类只剩下一个方法 Print()，它调用 ReportPrinter 的类方法 Print。 DataAccess 和 ReportFormatter 似乎有责任，但 ReportPrinter 依赖于 DataAcess 和 ReportFormatter，所以这不会破坏 SRP 还是我误解了它？
In the following video, the author takes an existing class and assigns the Single Responsibility Principle to it. He takes a Print Class that has the job of Accessing Data, Formatting, and Printing the report. He breaks up each method to its own class, so he creates a DataAccess class to handle data access, he creates a ReportFormatter class to handle the formatting of the Report, and he creates a ReportPrinter class to handle the printing of the Report. The original Report class is then left with one method, Print() which calls the ReportPrinter's class method Print. DataAccess and ReportFormatter appear to have responsibility, but ReportPrinter relies on DataAcess and ReportFormatter, so doesn't this break the SRP or am I misunderstanding it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
单一职责原则表明给定的类应该具有单一职责（或“更改原因”）。 它本身并不表明如何履行该责任。 这样做可能而且经常需要多个其他类作为协作者进行合作。
The Single Responsibility Principle indicates that a given class should have a single responsibility (or 'reason to change'). It does not, in and of itself, indicate how that responsibility is to be satisfied. Doing so can, and often does, require the cooperation of multiple other classes as collaborators.
不看视频，听起来这个设计很合理。 SRP 并没有被破坏，因为处理数据访问的方法没有出现在 ReportPrinter 类中，只有“我可以调用某些东西来获取我想要的数据”的概念。
您可以更进一步，让一个协调器类只负责协调数据访问类、格式化程序类和打印机类的活动。 您还可以以不同的方式排列对象，例如让协调器将数据发送到格式化程序，格式化程序将其发送到打印机，而协调器不（直接）了解打印机。
必须了解一些有关协调狭隘对象的努力的知识。 这成为他们的责任。 只要您不知道或不关心它们如何做，了解其他对象将做什么的想法或概念就可以了。 将接口视为“责任接缝”是一个好的开始。
如果您将对象视为相互传递数据而不是“做”事情，这也会很有帮助。 因此，ReportFormatter 返回（或转发）一个表示格式化报表的新对象，而不是（概念上）在现有报表上执行对象。
Without watching the video, it sounds like a reasonable design. SRP is not broken, as methods dealing with data access do not appear in the ReportPrinter class, only the concept that "I can call something to get the data I want."
You could push it a bit further, and have a coordinator class responsible only for coordinating the activities of the data access class, the formatter class, and the printer class. You could also arrange the objects in different ways, like having the coordinator sends data to the formatter, which sends it to the printer, and the coordinator doesn't (directly) know about the printer.
Something has to know about coordinating the efforts of the narrowly-focused objects. That becomes their responsibility. It's okay to know about the idea or concept of what the other objects will do, so long as you don't know or care how they do it. Thinking of interfaces as "seams of responsibility" is a good start.
It can also be helpful if you think of objects as passing data to each other, rather than "doing" things. So the ReportFormatter returns (or forwards) a new object representing a formatted report, rather than (conceptually) performing objects on an existing report.
不会。它不会破坏建议零售价。
假设
事件尽管
ReportPrinter 依赖于 DataAccess 和 ReportFormatter，但IDataAccess 或 IReportFormatter契约的任何更改都应由DataAccess 和 ReportFormatter实现分别。ReportPrinter不担心这些类中的责任变化。您可以使用
Composition或实现 Mediator 模式在这三个类之间提供松散耦合并完成工作。 让耦合部分远离责任。No. It does not break SRP.
Assume that
Event though
ReportPrinter relies on DataAccess and ReportFormatter, any change in contract ofIDataAccess or IReportFormattershould be implemented byDataAccess and ReportFormatterrespectively.ReportPrinterdoes not worry about the responsibility changes in those classes.You can have
Compositionor implement Mediator pattern to provide loose coupling between these three classes and get job done. Keepcouplingpart away fromresponsibility.SRP 不解决依赖性问题。 将类分解为单一职责类将有助于稍后打破这些依赖关系。 SRP 解决了经常一起提到的两个原则之一：内聚和耦合。 SRP 是关于高内聚的，依赖关系可以表明高耦合。 好的设计具有高内聚和低耦合。 有时这两个原则可能会不一致。
SRP doesn't address dependencies. Breaking the class up into the single-responsibility classes will facilitate breaking those dependencies later. SRP addresses one of the two principles oftem mentioned together: Cohesion and Coupling. SRP is about high cohesion, and the dependencies can be indicative of high coupling. Good designs have high cohesion and low coupling. Sometimes these two principles can be at odds.