Единственная ответственность и миксин

Question

Учитывая, что Миксины обычно вводят новое поведение в класс, это, как правило, подразумевает, что у класса будет более одного поведения.

Если у класса есть одна ответственность, это определяется каккласс имеет только одну причину для изменения.

Итак, я вижу это с двух разных точек зрения

1. У класса есть только одна причина для изменения.Модуль, добавленный в него, также имеет только одну причину для изменения.Если класс будет изменен, только класс нуждается в повторном тестировании.Если модуль заменен, только модуль нуждается в повторном тестировании.Следовательно, SRP не поврежден.

2. У класса теперь есть две причины для изменения.Если класс изменяется, и класс, и модуль требуют повторного тестирования.Если модуль изменяется, снова и класс, и модуль требуют повторного тестирования.Хенге, нарушается SRP.

Нарушает ли использование миксинов принцип единой ответственности , и в конечном итоге это усложняет обслуживание системы?

Answer 1

Учитывая, что миксины обычно вводят новое поведение в класс, это обычно подразумевает, что класс будет иметь более одного поведения.

Если бы это было правдой, это было бы в равной степени верно и для одиночного (реализации) наследования. Хотя никто больше не любит иерархии наследования с 23 глубинами, у него все еще есть место.

Причина, по которой наследование не нарушает SRP, заключается в том, что класс, о котором он говорит, является классом в смысле файла буквального кода, а не чем-то более абстрактным. Этот файл обычно не нужно менять, если вы изменяете файл кода базового класса.

Таким образом, единственная причина изменить его сохраняется.

Answer 2

Я думаю, это зависит от миксина.Это может дать ему дополнительные обязанности, но есть такие, как Ruby's Comparable , которые предоставляют довольно низкоуровневую функциональность, которая, я бы сказал, не нарушает SRP.

Answer 3

Когда вам нужно поделиться поведением между несвязанными классами (а иногда и вам нужно), по сути, есть три варианта:

1. Копирование и вставка везде.Это нарушает DRY, гарантированно нарушает удобство сопровождения.
2. Поместите его в абстрактный класс и пусть все ваши классы (многие из которых не связаны друг с другом) наследуются от него.Это обычно считается антипаттерном ОО.Проще говоря, это полностью выбивает концепцию наследования из головы.Просто потому, что foo и bar делают некоторые вещи одинаково, вы не утверждаете, что foo is-a bar .
3. Поместите его куда-нибудь еще, дайте ему четкое имя и смешайте его ввсе классы, которые в этом нуждаются.

Что касается тестирования, я бы сказал, что "хороший" миксин, как и хороший обычный метод, должен быть достаточно свободно связан, чтобы он и классы, использующие его, могли бытьиспользуется независимо.

Answer 4

Я бы с этим согласился.Однако SRP может (или должен) быть нарушен , иногда .