oop - 单一职责原则与贫血领域模型反模式

Question

我所在的项目非常重视单一职责原则。我们有很多小类，事情很简单。然而，我们有一个贫乏的领域模型——我们的任何模型类中都没有行为，它们只是属性包。这并不是对我们设计的提示 - 它实际上看起来工作得很好

在设计审查期间，每当向系统添加新行为时，SRP就会被引入，因此新行为通常会出现在新类中。这使得事情非常容易进行单元测试，但有时我感到困惑，因为这感觉就像将行为从相关的地方拉出来。

我正在努力提高对如何正确应用 SRP 的理解。在我看来，SRP 反对向一个对象添加共享相同上下文的业务建模行为，因为该对象最终不可避免地要么做不止一件相关的事情，要么做一件事情但知道改变形状的多个业务规则其输出。

如果是这样，那么感觉最终结果是一个贫乏的领域模型，这在我们的项目中确实是这样。然而贫血领域模型是一种反模式。

这两种想法可以共存吗？

编辑:一些与上下文相关的链接:

建议零售价 - http://www.objectmentor.com/resources/articles/srp.pdf
贫血域模型 - http://martinfowler.com/bliki/AnemicDomainModel.html

我不是那种只喜欢寻找先知并遵循他们所说的福音的开发者。因此，我不会提供这些链接来作为陈述“这些是规则”的方式，而只是作为这两个概念的定义来源。

Answer 1

富域模型 (RDM) 和单一职责原则 (SRP) 并不一定矛盾。 RDM 与 SRP 的一个非常专业的子类更不一致 - 该模型提倡“数据 bean + Controller 类中的所有业务逻辑”(DBABLICC)。

如果您阅读马丁的 SRP chapter ，您将看到他的调制解调器示例完全位于域层中，但将 DataChannel 和 Connection 概念抽象为单独的类。他将调制解调器本身保留为包装器，因为这对于客户端代码来说是有用的抽象。这更多的是关于正确的(重新)分解，而不仅仅是分层。内聚和耦合仍然是设计的基本原则。

最后，三个问题:

• 正如 Martin 自己所说，找出不同的“变革原因”并不总是那么容易。 YAGNI、敏捷等概念本身就阻碍了对 future 变革原因的预期，因此我们不应该发明那些不是立即显而易见的概念。我认为“过早的、预期的变更原因”是应用 SRP 的一个真正风险，应该由开发人员管理。

• 除上述之外，即使是正确的(但不必要的)SRP 应用也可能会导致不必要的复杂性。永远想想下一个必须维护你的类的可怜虫:将琐碎行为勤奋地抽象成自己的接口(interface)、基类和单行实现真的有助于他理解什么应该只是一个类吗？

• 软件设计通常是为了在竞争力量之间取得最佳妥协。例如，分层架构主要是 SRP 的良好应用，但是，例如，将业务类的属性从 boolean 更改为 >enum 在所有层中产生链式 react - 从数据库到域、外观、Web 服务，再到 GUI？这是否表明设计不好？不一定:它表明你的设计倾向于从一个方面改变到另一个方面。