外观模式是否违反了SRP？

Question

SRP校长说：

类或模块应该有一个(而且只有一个)需要更改的原因。

我有一些Facade类作为服务层类。例如SaleService，它提供了一些方法，如SaveOrder()，CancelOrder()，CreateOrder()，GetAllOrders()，GetAllPlannedOrders()，.

我把它们放在一起是因为它们的概念关系。

在这种方法中使用此类类(可能有不止一个更改()的原因)是否违反了SRP？如果是，我如何处理这个问题？

Answer 1

正面模式本身并不违反SRP。通常，外观模式隐藏了底层对象之间的复杂交互。在这种情况下，外观的“唯一责任”是管理这些交互。只要这些交互不改变，你的外表就不应该改变。如果交互变得非常复杂，可能有必要再次将facade的实现拆分到多个对象中。

如果我看一下你的例子，我不会觉得你真的想隐藏复杂性，所以在这里重新考虑正面模式的使用可能会很有趣。

Answer 2

我认为SRP的目的是确定一个类做得太多的情况，更好的设计是有多个类。一个典型的例子: ReportProducer类，它做一些组装数据的工作，还有一些工作来格式化输出，可能应该有两个类:一个用于收集，一个用于格式化。这种方法的好处之一是灵活性:我们可以使用单个集合类和多个不同的格式化程序类。

现在，您的例子看起来相当合理，您有一个连贯的类，所有的方法都是相关的，类的用户知道这是类的订单。对我来说这似乎是一个单一的责任。

改变的原因是什么？在报告示例中，我们有两种完全不同的更改:可能是数据来自更改的地方，或者是所需的格式更改。在您的例子中，人们可能会认为还有许多可能的原因:订单的“形状”可能会改变，所需的接口可能会改变(例如。添加queryCancelledOrders()方法)您可能要更改的外观的后端。但是，我不认为这些迹象表明您违反了SRP:它们都与提交操作订单的接口的任务有关。

如果我们把“改变的单一原因”完全从字面上说，那么我不相信我们会写任何一门课。我们总是有接口和实现，通常也有一些依赖类。其中任何一个都可能会改变，所以我们总是至少有两个，也可能有三个原因来改变。

相反，想想“这类责任是什么？”你能不用“和”这样的词用“sentance”来表达它吗？坏:收集数据和格式报告。

Answer 3

SRP是关于一个责任的实现细节的更改，它可能导致类被修改，即使这个责任只是类的一小部分。

一个正面不能违反SRP的精确，更严重的方式，因为它只是一个表面的反映-它不会改变每次内部的操作变化。当其中一个操作的名称发生变化时，它可能会发生变化，这确实会导致一些脆性，但并不可怕，或者当我们希望通过外观反射的操作被移除或添加时--但这更多地与Facade选择公开的内容有关，这实际上是它的实际责任。

当我希望通过代码通过一个入口点使用第三方组件时，我通常使用Facade。这方面的一个例子是反腐败层模式。但是，对于为我自己的代码创建外观，我通常会三思而后行，因为它的便利性很容易赢得您的支持，这可以防止您真正考虑对象之间的依赖关系。

不过，我不确定在您的示例中SaleService是否真的是一个外观，因为服务通常不仅仅是重定向到某些业务行为(它们可以进行日志记录、授权、事务管理、协调对业务的多个调用等等)。