单一职责和混合答案

【问题标题】：Single Responsibility and Mixins单一职责和混合
【发布时间】：2011-03-17 23:55:27
【问题描述】：

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

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

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

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

【问题讨论】：

【解决方案1】：

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

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

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

【讨论】：

如果您需要在不相关的类之间共享行为，这听起来完全像是另一个类的工作。它可以通过没有继承或混合的接口来处理那些不相关的类之间所需的行为。这会处理 SRP 和 DRY。

【解决方案2】：

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

【讨论】：

【解决方案3】：

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

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

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

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

【讨论】：

【解决方案4】：

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

【讨论】：