单一责任和混合

Question

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

如果一个类只有一个责任,则将其定义为只有一个改变原因的类.

所以,我可以从两个不同的角度看待这一点

1. 这个班只有一个改变的理由.混合的模块也只有一个变化的原因.如果更改了类,则只需要重新测试类.如果更改模块,则只需要重新测试模块.因此,SRP是完整的.

2. 该班现在有两个改变的原因.如果更改了类,则类和模块都需要重新测试.如果更改了模块,则类和模块都需要重新测试.Henge,SRP受到侵犯.

mixin的使用是否违反了单一责任原则,最终导致系统难以维护？

Answer 1

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

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

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