Single Responsibility and Mixins

Question

Given that Mixins generally introduce new behaviour into a class, this generally implies that a class would have more than one behaviour.

If a class has a single responsibility this is defined as the class having only one reason for change.

So, I can see this from two different perspectives

1. The class only has one reason for change. The module mixed in also has only one reason for change. If the class is changed only the class will need retesting. If the module is changed only the module needs retesting. Hence, SRP is intact.

2. The class now has two reasons for change. If the class is changed, both class and module need retesting. If the module is changed, again both class and module need retesting. Henge, SRP is violated.

Does the use of mixins violate the Single Responsibility Principle, and ultimately result in a harder to maintain system?

Answer 1

When you need to share behaviour among unrelated classes (and sometime you need to), there are essentially three options:

1. Copy and paste everywhere. This violates DRY, is guaranteed to hurt maintainability.
2. Put it into an abstract class and let all your classes (many of which are unrelated to each other) inherit from it. This is commonly considered an OO antipattern. Simply put, it totally knocks the concept of inheritance on the head. Just because foo and bar do some things the same, you don't claim that foo is-a bar.
3. Put it somewhere else, give it a clear name, and mix it into all classes that need it.

As for testing, I would argue that a "good" mixin, just like a good regular method, should be coupled loosely enough that it and the classes using it can be used independently.