design-patterns - 单一职责和混合

Question

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

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

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

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

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

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

Answer 1

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

到处复制粘贴。这违反了 DRY，肯定会损害可维护性。

把它放到一个抽象类中，让你所有的类(其中许多彼此无关)都继承自它。这通常被认为是一种 OO 反模式。简而言之，它完全颠覆了继承的概念。仅仅因为 foo 和 bar 做一些相同的事情，你不会声称 foo 是一个 bar。

把它放在别的地方，给它一个清晰的名字，然后把它混入所有需要它的类中。

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