SRP负责人说：
一个类或模块应该只有一个改变的原因
我有一些Facade类作为我的服务层类。例如SaleService，它提供了一些方法，例如SaveOrder()，CancelOrder()，CreateOrder()，GetAllOrders()，GetAllPlannedOrders()，...
由于他们的概念关系，我只把它们放在一起 使用这种方法的类可能有多个改变（）的原因，违反了SRP吗？如果是的话，我该如何处理这个问题？
答案 0 :(得分：7)
外观模式本身并不违反SRP。通常，立面图案隐藏了底层对象之间的复杂交互。在这种情况下，外观的“单一责任”是管理这些交互。只要这些互动没有改变，你的外观就没有理由改变。如果交互变得非常复杂，那么将门面的实现再次分成多个对象可能是值得的。
如果我看一下你的例子，我不会觉得你真的试图隐藏复杂性，所以在这里重新考虑外观模式的使用可能会很有趣。
答案 1 :(得分：2)
我认为SRP的目的是识别一个类做得太多的情况，更好的设计是多个类。一个典型的例子：一个ReportProducer类，它做一些工作来组装数据和一些更多工作来格式化输出，可能应该有两个类：一个用于收集，一个用于格式化。这种方法的好处之一是灵活性：我们可以使用单个聚类和多个不同的格式化类。
现在你的例子似乎很合理，你有一个连贯的类，所有的方法都是相关的，类的用户知道这是去Orders的类。这对我来说只是一个责任。
改变的原因是什么？在报告示例中，我们有两种完全不同的更改：可能是数据来自更改，也可能是所需的格式更改。在你的例子中，有人可能会争辩说还有多种可能的原因：Order的“形状”可能会改变，所需的界面可能会改变（例如，添加一个queryCancelledOrders（）方法）后端你是一个Facade可能会改变。但是我不认为这些是你违反SRP的迹象：它们都与呈现操纵订单的界面有关。
如果我们完全按照“改变的单一理由”那么我不相信我们可以写任何课程。我们总是有接口和实现，通常还有一些依赖类。其中任何一个都可能发生变化，因此我们总是至少有两个甚至三个变化的原因。
反而想到“这个班的责任是什么？”你能否在不使用诸如“AND”之类的词语的情况下表达它。不好：收集数据和格式报告。
答案 2 :(得分：1)
SRP是关于一项责任的实施细节的变化，即使该责任只是该课程的一小部分，也可能导致课程被修改。
Facade不能以那种精确，更严肃的方式违反SRP，因为它只是表面的反映 - 每次操作的内部变化时都不会改变。当其中一个操作的名称发生变化时，它可能会发生变化，这会导致一些脆弱但没什么可怕的，或者当我们希望通过Facade反映的操作被删除或添加时 - 但这更多的是做Facade选择公开的内容， 实际上是它的实际责任。
当我希望通过我的代码通过单个入口点使用第三方组件时，我经常使用Facade。一个例子是Anti-Corruption Layer模式。我通常会考虑将Facades创建到我自己的代码中，因为您可以通过它的方便轻松地赢得它，这可以防止您真正考虑对象之间的依赖关系。
我不确定SaleService在您的示例中是否真的是Facade，因为服务通常不只是重定向到某些业务行为（他们可以执行日志记录，授权，事务管理，协调多个调用到业务等。）