Single Responsibility y Mixins

Question

Dado que Mixins generalmente introduce un nuevo comportamiento en una clase, esto generalmente implica que una clase tendría más de un comportamiento.

Si una clase tiene una sola responsabilidad, esto se define como la clase que tiene solo un motivo para el cambio.

lo tanto, puedo ver esto desde dos perspectivas diferentes

1. La clase sólo tiene una razón para el cambio. El módulo mezclado también tiene solo una razón para el cambio. Si se cambia la clase, solo la clase necesitará una nueva prueba. Si se cambia el módulo, solo el módulo necesita una nueva prueba. Por lo tanto, SRP está intacto.

2. La clase ahora tiene dos motivos para el cambio. Si se cambia la clase, tanto la clase como el módulo necesitan una nueva prueba. Si se cambia el módulo, una vez más, tanto la clase como el módulo necesitan una nueva prueba. Henge, SRP es violado.

¿El uso de mixins violan la Single Responsibility Principle, y en última instancia como resultado un sistema más difícil de mantener?

Answer 1

Cuando tenga que compartir comportamiento entre clases no relacionadas (y en algún momento se necesita), existen básicamente tres opciones:

1. copiar y pegar en todas partes. Esto viola el DRY, se garantiza que perjudica la capacidad de mantenimiento.
2. Ponlo en una clase abstracta y permite que todas tus clases (muchas de las cuales no están relacionadas entre sí) hereden de ella. Esto se considera comúnmente como un antipatrón OO. En pocas palabras, golpea totalmente el concepto de herencia en la cabeza. El hecho de que foo y bar hagan algunas cosas de la misma manera, no afirma que foo es-una barra.
3. Colóquelo en otro lugar, asígnele un nombre claro y mézclelo en todas las clases que lo necesiten.

En cuanto a las pruebas, yo diría que una mixin "buena", al igual que un buen método regular, debe acoplarse lo suficientemente como para que ella y las clases que la utilizan puedan usarse de forma independiente.

Answer 2

Estoy de acuerdo con eso. Sin embargo, el SRP puede (o debe) ser violado a veces.

Answer 3

Creo que depende de la mezcla. Bien podría darle responsabilidades adicionales, pero hay aquellos como Ruby's Comparable que dan bastante funcionalidad de bajo nivel que diría que no viola a SRP.

Answer 4

Dado que Mixins generalmente introduce un nuevo comportamiento en una clase, esto generalmente implica que una clase tendría más de un comportamiento.

Si eso fuera cierto, sería igualmente cierto para la herencia única (implementación). Si bien a nadie le gustan las jerarquías de herencia de 23 niveles, todavía tiene su lugar.

La razón por la que la herencia no rompe el SRP es que la clase de la que habla es la clase en el sentido de un archivo de código literal, no es nada más abstracto. Ese archivo generalmente no necesita cambiar si cambia un archivo de código de clase base.

Así que la única razón para cambiarlo se conserva.