2. Principio de Responsabilidad Única Una clase debe tener una, y solo una razón para cambiar ¿Por qué es importante mantener las responsabilidades en clases separadas? Por que cada responsabilidad es un eje de cambio. Cuando los requerimientos cambian, esos cambios se manifiestan a través de un cambio de responsabilidades a través de las clases. Si una clase asume más de una responsabilidad, entonces habrá más de una razón para modificarla.
3. Principio de Responsabilidad Única(2) Si una clase tiene mas de una responsabilidad, entonces estas responsabilidades se acoplan. Los cambios en una responsabilidad pueden afectar o inhibir la habilidad de la clase para cumplir con las demás. Este tipo de acoplamiento resulta en diseños frágiles que se rompen de formas inesperadas cuando hay cambios.
6. Principio Abierto Cerrado Debe ser posible extender el comportamiento de una clase, sin modificarlo. Los módulos que conforman el principio abierto-cerrado tienen dos atributos principales.
7. Abiertos a la extensión Están “Abiertos para la extensión”. Esto significa que el comportamiento del modulo puede ser extendido. Se puede hacer que el modulo se comporte de maneras nuevas y diferentes conforme cambien los requerimientos de la aplicación, o para cumplir con los requerimientos de nuevas aplicaciones.
8. Cerrados a la modificación Están “Cerrados a la modificación”. El código fuente de estos módulos es inviolable. Nadie tiene permitido hacer cambios en sus códigos fuentes. Los módulos deben tener una interfaz estable y bien definida que no se modificará para no afectar a otros módulos que dependan de ellos.
9. Claves del principio Abierto-Cerrado El código bien diseñado puede ser extendido sin modificaciones; y que en los programas bien diseñados, se pueden agregar características nuevas agregando nuevo código, en ves de cambiar código antiguo que ya funciona. Nota: La abstracción y el polimorfismo son la clave
10. Principio de inversión de dependencias Se debe depender de abstracciones, no de cosas concretas. Los módulos de alto nivel no deben depender de módulos de bajo nivel. Ambos deben depender de abstracciones. Las abstracciones no deben depender de detalles. Los detalles deben depender de las abstracciones.
11. Principio de sustitución de Liskov Las funciones que usan referencias a clases base, deben ser capases de usar objetos de clases derivadas sin darse cuenta La importancia de este principio se hace evidente cuando deja de cumplirse.
14. Principio de segregación de interfaces Los clientes de una clase no deben depender de interfaces que no utilizan. Este principio se ocupa de las desventajas de las interfaces “gordas”. Las clases que tienen interfaces “gordas ” son clases cuyas interfaces no son cohesivas.
15. En otras palabras, las interfaces de las clases pueden ser separadas en grupos de funciones miembro. Cada grupo sirve a un conjunto distinto de clientes. Por lo que algunos clientes usan un grupo de funciones miembro, y otros clientes usan los otros grupos. Principio de segregación de interfaces