PRINCIPIO SOLID

• S. Single responsibility principle

• O. Open / closed
• L. Liskov substitution principle
• I. interface segregation principle
• D. Dependency inversión principle
 Principio de Responsabilidad Única

Una clase debería tener una única responsabilidad.

El principio de responsabilidad única establece que cada clase debería ser
responsable únicamente de una parte de la funcionalidad que proveerá
nuestro software. Esto suena bien, pero... ¿a qué se refiere con "ser
responsable"?
 ¿Qué es una responsabilidad?

En el contexto de este principio una responsabilidad puede ser definida como

“una razón para cambiar”. Si sustituimos “responsabilidad” por “razón para
cambiar” nos queda:
Una clase debería tener solo una razón para cambiar.
Ahora... ¿cómo identificamos que nuestras clases tienen solo una razón para
cambiar?
 Importancia de uso
• Una implementación sencilla
• Mas fácil de entender
• Previene cualquier daño colateral al momento de hacer una cambio
¿Qué posibles consecuencias trae que nuestras clases tengan más de una responsabilidad?

Si una clase tiene más de una responsabilidad, habrá entonces más de

una razón para que cambie. Lo que implica que el cambio a una de ellas
puede afectar a la otra, incluso nos puede imposibilitar satisfacer
ambas.
 ¿Cómo detectar si estamos violando el
Principio de Responsabilidad Única?
• En una misma clase están involucradas dos capas de la arquitectura:
• El número de métodos públicos
• Por el número de imports
• Nos cuesta testear la clase
• cada vez que escribes una nueva funcionalidad, esa clase se ve
afectada
• Por el número de líneas
• coche){ ... } }
CONCLUSION