Principios fundamentales de la Programación Orientada a Objetos SOLID

Principios fundamentales de la Programación Orientada a Objetos SOLID

1. Interface Segregation Principle, ISP (principio de segregación de interfaces)

   • Principio de segregación de interfaces
     • Los clientes no deben ser forzosamente dependientes de las interfaces que no utilizan.
       • Otorga una mayor cohesión al sistema
     • Se trata de definir múltimples interfaces sencillos y luego las clases implementan un subconjunto de ellos

2. Aspectos fundamentales

   • Cohesión
   • Acoplamiento
   • Encapsulación
     • Saber que se puede hacer con él pero no como está hecho

3. Guía a seguir durante la fase de desarrollo para facilitar el mantenimiento de las aplicaciones

4. Single Responsability Principle - SRP

   • Principio de responsabilidad única
     • Una clase debe tener una y solo una única causa por la cual puede ser modificada

5. Principio Open/Closed - OCP

   • El principio YAGNI ("You Ain’t Gonna Need It" o "No vas a necesitarlo")
     • Desarrollar ahora sobre los requisitos funcionales actuales, no sobre los que supongamos que aparecerán dentro de un mes
       • Clases con OCP
         • Son abiertas para la extensión
         • Son cerradas para la modificación
       • Se trata de que al añadir una funcionalidad no haya que modificar código sino extenderlo. Ejemplo el patrón State
       • Claves
         • Abstracción y el polimorfismo

6. Liskov Substitution Principle, LSP

   • Sustitución de Liskov
     • Diseño por Contratos (Design by Contract – DbC

7. Dependency Inyection, DI

   • Principio de Inyección de dependiencias
     • TNTWIWHDI (That’s Not The Way I Would Have Done It, "Yo no lo habría hecho así")
     • Cuando los cambios tienen una repercusión en otras entidades, no necesariamente dependientes, se dice que un sistema o aplicación es frágil
     • El termino inmovil lo utilizamos para medir el nivel de dependencia entre una parte del diseño y otros datos no directos.
     • Se trata de eliminar las dependencias utilizando por ejemplo el patrón Fachada (usando Interfaces)
     • Las clases de alto nivel no deberían depender de las clases de bajo nivel. Ambas deberían depender de las abstracciones.
     • Las abstracciones no deberían depender de los detalles. Los detalles deberían depender de las abstracciones.
   • Inversion of Control, IoC