单一职责和混合类

Question

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

如果一个类只有一个职责，那么这被定义为该类仅具有一种更改原因。

因此，我可以从两个不同的角度看待这个问题

1. 类仅具有一个更改原因。混合模块也仅具有一个更改原因。如果仅更改类，则仅需要重新测试类。如果仅更改模块，则仅需要重新测试模块。因此，SRP完好无损。

2. 类现在具有两个更改原因。如果更改类，则需要重新测试类和模块。如果更改模块，则再次需要重新测试类和模块。因此，SRP被违反了。

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

- Mongus Pong

Answer 1

我认为这取决于 mixin。它可能会增加额外的职责，但像 Ruby's Comparable 这样的 mixin 给出的是相当低级别的功能，我认为不会违反 SRP。

- Grant Crofton

Answer 2

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

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

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

- user395760

---

如果您需要在不相关的类之间共享行为，那么另一个类似乎是一个合适的选择。它可以通过接口处理这些不相关类之间所需的行为，而无需使用继承或混入。这样可以实现SRP和DRY。 - Tek

Answer 3

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

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

继承不破坏 SRP 的原因在于它所涉及的类是指代码文件的文字意义上的类，而不是更抽象的概念。如果你改变了一个基类代码文件，这个文件一般不需要改变。

因此，唯一需要改变它的原因得以保留。

- soru

Answer 4

我同意这个观点。然而，单一职责原则有时候可以（或应该）被违反。

- Matthew Groves