单一职责原则的缺点答案

【问题标题】：Disadvantage of Single Responsibility Principle单一职责原则的缺点
【发布时间】：2014-11-10 17:30:32
【问题描述】：

我已经阅读了几本书并听过有关软件设计的讲座。但是我不知道如何解决遵循 OO 设计原则引起的问题。

这里有一些情况。我开始设计简单的单类（ClassA）。之后，ClassA 也肩负着类似的责任。根据单一职责原则，我从 ClassA 到 ClassB 中提取了一些逻辑。 ClassA 再次变得足够简单。但是，ClassA 的职责可能与 ClassB 的职责相似，使 ClassA 和 ClassB 有相互引用作为成员字段或属性进行合作。换句话说，类的分离产生了另一种复杂性。那是单独的类之间的交互。从那以后，ClassA 和 ClassB 中的每一个都可能带着更复杂的责任成长起来，并且某些类（ClassC 或 ClassD）可能与 ClassA 或 ClassB 分开。现在，类之间的交互变得更加复杂。每个类都可以引用其他类作为成员字段或方法参数。

随着单个类变得更简单，类的数量增加，类之间的关系和交互的复杂性也增加。

在某些幸运的情况下，它可以通过设计模式来解决。然而，在许多情况下，类的分离使类的关系更加复杂。并倾向于生成对其他类作为成员的引用过多的类。一个类有太多对其他类的引用作为成员是很难测试的。

我已经阅读了几本 OO 设计书籍。他们中的大多数人都说简单的课程很好。然而，它们都没有关注由 SRP 引起的类交互的复杂性。

我错过了什么吗？我该如何解决这个问题？

【问题讨论】：

一般来说，最好有更多的类，每个类都有单独的职责，而不是有更少的类，每个类都有复杂的职责。您所描述的情况是重构以维护 SRP 的常见结果。

标签： single-responsibility-principle

【解决方案1】：

责任意味着改变的一个理由。

由于一个原因，您可能需要更改 A 类，并且您可能不小心更改了 A 类中另一个职责的行为。有时您只需要使用或测试 A 类的一项功能，但您需要创建一个完整的 A 类。

如果不将A类分为A、B、C、D类，职责之间的交互仍然存在，但隐藏在A类中。

使类更加连贯，交互更加明确，将使您的代码更易于维护。

【讨论】：

谢谢，但我不确定后一种情况是否更易于维护。如果我比较 BigClassA 具有一些数据字段，而 SmallClassA 具有完全相同的数据字段以及对 ClassB、ClassC 和 ClassD 的附加引用，我认为 SmallClassA 的可测试性较低，因为我不仅要关心数据字段，还要关心对 ClassB、ClassC 的引用和 ClassD 可能会产生副作用。
所以你的 A 类应该持有 B、C 和 D 类的接口，而不是与它们解耦的具体类。当你测试类 A 时，给假类继承类 A 持有的接口。然后，您可以确保 B、C 和 D 没有发生副作用。
这就是为什么我说 SmallClassA 的可测试性不如 BigClassA。这是因为我必须关心其他事情。

【解决方案2】：

我认为从班级规模的角度考虑 srp 是不好的。我认为你应该考虑演员和改变的理由。

演员是想要改变你的班级的角色。例如，如果您有这样的课程：

class User
{
  public function calculatePay()
  public function save()

}

两个不同的角色想要改变你的班级。例如，会计想要更改 calculatePay 方法，而数据库管理员想要更改 save() 方法。这个类可能会因为两个不同的原因而改变。

我认为最好从“将出于相同原因而发生变化的事物组合在一起”的角度来考虑 srp。

【讨论】：