El principio de responsabilidad única ( SRP ) es un principio de programación de computadoras que establece que cada módulo , clase o función en un programa de computadora debe tener responsabilidad sobre una sola parte de la funcionalidad de ese programa , y debe encapsular esa parte. Todo eso de la función módulo, clase o servicios deben estar alineados estrechamente con esa responsabilidad. [1]
Robert C. Martin , el creador del término, expresa el principio como, "Una clase debe tener una sola razón para cambiar", [1] aunque, debido a la confusión en torno a la palabra "razón", también afirmó "Este principio se trata de personas.". [2] En algunas de sus charlas, también argumenta que el principio es, en particular, sobre roles o actores. Por ejemplo, si bien pueden ser la misma persona, la función de un contador es diferente a la de un administrador de base de datos. Por lo tanto, cada módulo debe ser responsable de cada función. [3]
Historia
El término fue introducido por Robert C. Martin en un artículo con el mismo nombre como parte de sus Principios de diseño orientado a objetos , [4] popularizado por su libro de 2003 Agile Software Development, Principles, Patterns, and Practices . [5] Martin lo describió como basado en el principio de cohesión , como lo describe Tom DeMarco en su libro Structured Analysis and System Specification , [6] y Meilir Page-Jones en The Practical Guide to Structured Systems Design . [7] En 2014, Martin escribió una publicación de blog titulada El principio de responsabilidad única con el objetivo de aclarar lo que se quería decir con la frase "razón para el cambio".
Ejemplo
Martin define una responsabilidad como una razón para cambiar y concluye que una clase o módulo debe tener una, y solo una, razón para cambiar (por ejemplo, reescribir).
Como ejemplo, considere un módulo que compila e imprime un informe. Imagine que un módulo de este tipo se puede cambiar por dos razones. Primero, el contenido del informe podría cambiar. En segundo lugar, el formato del informe podría cambiar. Estas dos cosas cambian por diferentes causas. El principio de responsabilidad única dice que estos dos aspectos del problema son en realidad dos responsabilidades separadas y, por lo tanto, deberían estar en clases o módulos separados. Sería un mal diseño acoplar dos cosas que cambian por diferentes razones en diferentes momentos.
La razón por la que es importante mantener una clase enfocada en una sola preocupación es que hace que la clase sea más sólida. Continuando con el ejemplo anterior, si hay un cambio en el proceso de compilación del informe, existe un mayor peligro de que el código de impresión se rompa si es parte de la misma clase.
Ver también
- Separación de intereses
- Ocultación de información
- Patrón de cadena de responsabilidad
- Cohesión (informática)
- Principio abierto / cerrado
- SOLID - la "S" en "SOLID" representa el principio de responsabilidad única
- GRASP (diseño orientado a objetos)
Referencias
- ↑ a b Martin, Robert C. (2003). Desarrollo de software ágil, principios, patrones y prácticas . Prentice Hall. pag. 95. ISBN 978-0135974445.
- ^ Martin, Robert C. (2014). "El principio de responsabilidad única" . El blog de código limpio .
- ^ Robert C. Martin (2018). Arquitectura limpia: una guía del artesano para la estructura y el diseño de software . Prentice Hall. ISBN 978-0-13-449416-6.
- ^ Martin, Robert C. (2005). "Los principios de OOD" . butunclebob.com .
- ^ Martin 2003 , págs.95-98
- ^ DeMarco, Tom. (1979). Análisis estructurado y especificación del sistema . Prentice Hall . ISBN 0-13-854380-1.
- ^ Page-Jones, Meilir (1988). La guía práctica para el diseño de sistemas estructurados . Yourdon Press Computing Series . pag. 82. ISBN 978-8120314825.
enlaces externos
- El secreto detrás del principio de responsabilidad única
- El principio de responsabilidad única