Единственный Responsibility и Mixins
Учитывая, что Mixins обычно вводят новое поведение в класс, это обычно подразумевает, что класс имел бы больше чем одно поведение.
Если класс несет единственную ответственность, это определяется как класс, имеющий только одну причину изменения.
Так, я вижу это от двух других точек зрения
Класс только имеет одну причину изменения. Модуль, смешанный в также, имеет только одну причину изменения. Если класс будет изменен, то только классу будет нужно перетестирование. Если модуль изменяется, только модулю нужно перетестирование. Следовательно, SRP неповрежден.
Класс теперь имеет две причины изменения. Если класс изменяется, и класс и перетестирование потребности модуля. Если модуль изменяется, снова и класс и перетестирование потребности модуля. Henge, SRP нарушен.
Использование mixins нарушает Единственный Принцип Ответственности и в конечном счете приводит к более твердому для обслуживания системы?
4 ответа
Когда вам нужно поделиться поведением между несвязанными классами (а иногда и нужно), есть три основных варианта:
- Скопировать и вставить везде. Это нарушает DRY, гарантированно ухудшает ремонтопригодность.
- Поместите его в абстрактный класс и позвольте всем вашим классам (многие из которых не связаны друг с другом) наследовать от него. Это обычно считается антипаттерном ОО. Проще говоря, это полностью сбивает с толку концепцию наследования. Просто потому, что foo и bar делают некоторые вещи одинаково, вы не утверждаете, что foo - это bar .
- Поместите его в другое место, дайте ему четкое имя и смешайте его со всеми классами, которые в нем нуждаются.
Что касается тестирования, я бы сказал, что «хороший» миксин, как и хороший обычный метод, должен быть связан достаточно слабо, чтобы его и использующие его классы можно было использовать независимо.
Я думаю, это зависит от миксина. Это могло бы дать ему дополнительные обязанности, но есть такие, как Ruby's Comparable , которые предоставляют довольно низкоуровневую функциональность, которая, я бы сказал, не нарушает SRP.
Учитывая, что миксины обычно вводят новое поведение в класс, это обычно означает, что у класса будет более одного поведения.
Если бы это было правдой, то это было бы так же верно и для одиночного (реализационного) наследования. Хотя никому больше не нравится 23-х уровневая иерархия наследования, ей все еще есть место.
Причина, по которой наследование не нарушает SRP, заключается в том, что класс, о котором идет речь, является классом в смысле буквального файла кода, а не чем-то более абстрактным. Этот файл обычно не нужно изменять, если вы изменяете файл кода базового класса.
Таким образом, единственная причина для его изменения сохраняется.
Я согласен с этим. Однако SRP может (или должен) иногда нарушаться .