Single Responsibility and Mixins

Question

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

如果一个班级有单一责任，则将其定义为只有一个变更理由的班级。

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

1. 类只有一个变更理由看到这一点。混入的模块也只有一个原因需要改变。如果班级改变，只有班级需要重新测试。如果模块更换，只有模块需要重新测试。因此，SRP是完整的。

2. 这个班现在有两个变化的原因。如果班级更改，班级和模块都需要重新测试。如果模块改变了，那么类和模块都需要重新测试。 Henge，SRP受到侵犯。

使用mixin是否违反了Single Responsibility Principle，最终导致系统维护困难？

Answer 1

当你需要共享无关类之间的行为（和某个需要），基本上有三个选项：

1. 复制并粘贴无处不在。这违反了DRY，保证会伤害可维护性。
2. 把它放到一个抽象类中，并让所有的类（其中很多是彼此不相关的）从它继承。这通常被认为是OO反模式。简而言之，它完全敲开了继承的概念。仅仅因为foo和bar做了一些相同的事情，你不会声称foo是 -。
3. 把它放在其他地方，给它一个明确的名字，并将其混合到所有需要它的类中。

至于测试，我认为，一个“好”混入，就像一个好普通的方法，应该再加足够宽松，它和类中使用它可以独立使用。

Answer 2

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

Answer 3

我认为这取决于mixin。它可能会给它额外的责任，但也有像Ruby's Comparable这些提供相当低级别的功能，我会说不违反SRP。

Answer 4

鉴于Mixin通常会将新行为引入类中，这通常意味着一个类将具有多个行为。

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

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

所以改变它的单一原因被保留下来。