design - solid - single responsibility principle
¿El Principio de Responsabilidad Individual es una regla de OOP? (6)
Una answer a una pregunta sobre desbordamiento de pila indicó que un marco particular violó una regla simple y simple de OOP: Principio de Responsabilidad Individual (SRP).
¿Es el principio de responsabilidad única realmente una regla de OOP?
Mi comprensión de la definición de Programación Orientada a Objetos es "un paradigma donde los objetos y su comportamiento se utilizan para crear software". Esto incluye las siguientes técnicas: Encapsulación, Polimorfismo y Herencia.
Ahora no me malinterpreten: creo que SRP es la clave para la mayoría de los buenos diseños de OO, pero creo que hay casos en los que este principio puede y debe romperse (al igual que las reglas de normalización de la base de datos). Presioné agresivamente los beneficios de SRP, y la gran mayoría de mi código sigue este principio.
Pero, ¿es una regla, y por lo tanto implica que no se debe romper?
Ahh, creo que esto se relaciona con una respuesta que di. :)
Como con la mayoría de las reglas y leyes, existen motivos subyacentes por los cuales estas reglas son relevantes: si el motivo subyacente no está presente o no es aplicable a su caso, entonces usted es libre de doblegar o romper las reglas de acuerdo con sus propias necesidades.
Dicho esto, SRP no es una regla de OOP per se, pero se considera una de las mejores prácticas para crear aplicaciones OOP que son fácilmente extensibles y comprobables por la unidad.
Ambas son características que considero de suma importancia en el desarrollo de aplicaciones empresariales, donde el mantenimiento de las aplicaciones existentes ocupa más tiempo que el nuevo desarrollo.
Como muchos de los otros carteles han dicho, todas las reglas están hechas para romperse.
Dicho esto, creo que SRP es una de las reglas más importantes para escribir un buen código. No es específico de la programación orientada a objetos, pero la parte de "encapsulación" de OOP es muy difícil de hacer bien si la clase no tiene una sola responsabilidad.
Después de todo, ¿cómo encapsula correcta y simplemente una clase con múltiples responsabilidades? Por lo general, la respuesta son múltiples interfaces y en muchos idiomas que pueden ayudar bastante, pero aún es confuso para los usuarios de su clase que pueda aplicarse de maneras completamente diferentes en diferentes situaciones.
Muy pocas reglas, si las hay, en el desarrollo de software son sin excepción. Algunas personas piensan que no hay lugar para ir, pero están equivocadas.
En lo que respecta a OOP, no hay una sola definición de orientación a objetos, por lo que dependiendo de a quién le pregunte obtendrá un conjunto diferente de principios, patrones y prácticas duros y blandos.
La idea clásica de OOP es que los mensajes se envían a objetos por lo demás opacos y los objetos interpretan el mensaje con conocimiento de sus propias entrañas y luego realizan una función de algún tipo.
SRP es un principio de ingeniería de software que se puede aplicar al rol de una clase, una función o un módulo. Contribuye a la cohesión de algo para que se comporte bien, sin trozos no relacionados cuelguen de él o tengan múltiples roles que se entrelazan y complican las cosas.
Incluso con solo una responsabilidad, eso puede ir desde una sola función hasta un grupo de funciones poco relacionadas que son parte de un tema común. Siempre y cuando evite manipular el jurado, un elemento que asume la responsabilidad de algo para lo que no fue diseñado originalmente o que hace algo ad hoc que diluya la simplicidad de un objeto y viole el principio que desee.
Pero me parece que es más fácil hacer que SRP sea correcto y luego hacer algo más elaborado que sea igual de robusto.
Ninguna de estas reglas son leyes. Son más pautas y mejores prácticas. Hay momentos en los que no tiene sentido seguir "las reglas" y debe hacer lo que sea mejor para su situación.
No tengas miedo de hacer lo que crees que es correcto. En realidad, puede inventar reglas nuevas y mejores.
Para citar al Capitán Barbossa:
"... Y en segundo lugar, debes ser pirata para que se aplique el código del pirata y tú no. Y en tercer lugar, el código es más de lo que llamarías" pautas "que las reglas reales ..."
Para citar a Jack Sparrow y Gibbs. "Pensé que se suponía que debías mantener el código". Sr. Gibbs: "Supusimos que eran directrices más reales".
Entonces claramente los piratas entienden esto bastante bien.
Las "reglas" se pueden entender a través del movimiento de patrones como "Fuerzas"
Entonces hay una fuerza tratando de hacer que la clase tenga una sola responsabilidad. (cohesión)
Pero también hay una fuerza que intenta mantener el acoplamiento con otras clases.
Al igual que con todo el diseño (no solo el código), la respuesta es que depende.
SRP es solo otra expresión de ISP :-).
Y la "P" significa "principio", no "regla": D