单一责任和混合

Question

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

如果一个班级只有一个责任，那么这被定义为只有一个改变理由的班级。

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

1. 该课程只有一个改变的理由。混合的模块也只有一个变化的原因。如果更改了类，则只需要重新测试类。如果更改模块，则只需要重新测试模块。因此，SRP完好无损。

2. 该课程现在有两个原因需要改变。如果更改了类，则类和模块都需要重新测试。如果更改了模块，则类和模块都需要重新测试。 Henge，SRP被侵犯了。

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

Answer 1

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

Answer 2

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

1. 复制并粘贴到处。这违反了DRY，保证损害可维护性。
2. 将它放入一个抽象类中，让所有类（其中许多类彼此无关）继承它。这通常被认为是OO反模式。简单地说，它完全破坏了头部的继承概念。仅仅因为foo和bar做了同样的事情，你并没有声称​​ foo是一个吧。
3. 把它放在其他地方，给它一个明确的名字，然后把它混合到所有需要它的类中。

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

Answer 3

  

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

如果这是真的，单一（实现）继承也同样如此。虽然没有人再喜欢23种深度的继承层次结构，但它仍然存在。

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

因此，保留更改它的唯一理由。

Answer 4

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