design-patterns - 单一职责和混合

Question

鉴于Mixins 通常会在一个类中引入新的行为，这通常意味着一个类会有多个行为。

如果一个类有一个单一的责任，这被定义为只有一个改变原因的类。

所以，我可以从两个不同的角度来看

1. 班级只有一个改变的理由。混入的模块也只有一个改变的理由。如果班级发生变化，只有班级需要重新测试。如果模块被改变，只有模块需要重新测试。因此，SRP 是完整的。

2. 班级现在有两个改变的原因。如果更改了类，则类和模块都需要重新测试。如果模块被更改，则类和模块都需要重新测试。Henge，SRP 被违反了。

使用 mixins 是否违反了单一职责原则，最终导致系统更难维护？

Answer 1

我认为这取决于mixin。它可能会赋予它额外的职责，但是像Ruby 的 Comparable这样的功能提供了相当低级的功能，我认为这不会违反 SRP。

Answer 2

当您需要在不相关的类之间共享行为时（有时您需要），基本上有三个选项：

1. 到处复制粘贴。这违反了 DRY，肯定会损害可维护性。
2. 把它放到一个抽象类中，让你所有的类（其中许多彼此无关）都继承自它。这通常被认为是一种 OO 反模式。简而言之，它完全颠覆了继承的概念。仅仅因为 foo 和 bar 做一些相同的事情，你不会声称foo is-a bar。
3. 把它放在别的地方，给它一个清晰的名字，然后把它混入所有需要它的类中。

至于测试，我认为一个“好的”mixin，就像一个好的常规方法一样，应该足够松散地耦合，以便它和使用它的类可以独立使用。

Answer 3

鉴于 Mixins 通常会在一个类中引入新的行为，这通常意味着一个类会有多个行为。

如果这是真的，那么单（实现）继承也同样如此。虽然没有人喜欢 23 深的继承层次结构，但它仍然占有一席之地。

继承不会破坏 SRP 的原因是它所讨论的类是文字代码文件意义上的类，而不是更抽象的类。如果您更改基类代码文件，该文件通常不需要更改。

所以改变它的唯一理由被保留了。

Answer 4

我同意这一点。但是，有时可以（或应该）违反 SRP 。