El principio de responsabilidad única ( SRP ) es un principio de programación informática que establece que "Un módulo debe ser responsable ante un solo actor". [1] El término actor se refiere a un grupo (formado por una o más partes interesadas o usuarios) que requiere un cambio en el módulo.
Robert C. Martin , el creador del término, expresa el principio como "Una clase debe tener solo una razón para cambiar". [2] Debido a la confusión en torno a la palabra "razón", más tarde aclaró su significado en una publicación de blog titulada "El principio de responsabilidad única", en la que mencionó la separación de preocupaciones y afirmó que "Otra redacción para el principio de responsabilidad única es: Reúne las cosas que cambian por las mismas razones. Separa las cosas que cambian por diferentes razones". [3] En algunas de sus charlas, también argumenta que el principio se refiere, en particular, a roles o actores. Por ejemplo, si bien pueden ser la misma persona, el rol de un contador es diferente al de un administrador de bases de datos. Por lo tanto, cada módulo debe ser responsable de cada rol. [4]
El término fue introducido por Robert C. Martin en su artículo "Los principios de OOD" como parte de sus Principios de diseño orientado a objetos , [5] popularizado por su libro de 2003 Desarrollo de software ágil, principios, patrones y prácticas . [6] Martin lo describió como basado en el principio de cohesión , como lo describe Tom DeMarco en su libro Análisis estructurado y especificación del sistema , [7] y Meilir Page-Jones en La guía práctica para el diseño de sistemas estructurados . [8] En 2014, Martin publicó 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". [1]
Martin define una responsabilidad como una razón para cambiar , y concluye que una clase o módulo debe tener una, y sólo una, razón para ser cambiado (por ejemplo, reescrito).
Como ejemplo, considere un módulo que compila e imprime un informe. Imagine que dicho módulo puede cambiar por dos razones. En primer lugar, 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 centrada en un único problema es que eso la hace más robusta. Siguiendo con el ejemplo anterior, si hay un cambio en el proceso de compilación de informes, existe un mayor riesgo de que el código de impresión se rompa si es parte de la misma clase.
{{cite book}}: Mantenimiento de CS1: falta la ubicación del editor ( enlace )