Nivel o grado de Interdependencia que tienen 2 unidades de software entre sí.

Unidades de software (clases, subtipos, métodos, módulos, funciones, bibliotecas, etc.).

• Si 2 unidades de software son independientes, entonces están desacoplados

Nota: Un sistema con bajo acoplamiento tiene alta cohesión y un sistema con baja cohesión tiene alto acoplamiento.

Un sistema con bajo acoplamiento indica un buen diseño de software

• Mejora la mantenibilidad de los sistemas de software desarrollando
• Aumenta la reutilización de unidades de software que se utilizan
• Minimiza riesgos de cambiar múltiples unidades de software al momento de realizar un cambio en el desarrollo

5 principios SOLID en ingles para desarrollar software de calidad

• S – Single Responsibility Principle (SRP)
• O – Open/Closed Principle (OCP)
• L – Liskov Substitution Principle (LSP)
• I – Interface Segregation Principle (ISP)
• D – Dependency Inversion Principle (DIP)

5 principios SOLID en español para desarrollar software de calidad

• S – Principio de Responsabilidad Única (SRP)
• O – Principio de Abierto/Cerrado (OCP)
• L – Principio de Sustitución de Liskov (LSP)
• I – Principio de Segregación de la Interfaz (ISP)
• D – Principio de Inversión de Dependencias (DIP)

El orden de SOLID no es importante (5 principios igual de importantes)

• Permite un desarrollo de software robusto y de bajo acoplamiento
• Permite escribir código limpio, reutilizable y mantenible en el tiempo
• Permite la escalabilidad en el desarrollo (añadir nuevas funcionalidades de forma ágil)

Grado en que elementos diferentes de un sistema permanecen unidos para alcanzar un mejor resultado

• La cohesión trabaja con elementos de una misma unidad de software (grado que permanecen juntos) .

Nota: La cohesión es la fuerza de relación entre las piezas de funcionalidad de una unidad de software dada.

Un sistema con alta cohesión indica un buen diseño de software

• Una alta cohesión significa que están muy relacionados.
• Una alta cohesión significa tener un sistema robusto, fiable y reutilizable.

Una clase debe tener una y solo una razón para cambiar.

• Reúne las cosas que cambian por las mismas razones y separa aquellas que cambian por razones diferentes.

Otra definición de SRP: Una clase solo debe tener una responsabilidad.

Nota: El principio de Responsabilidad Única es el más importante y fundamental de SOLID.

El código debe poder extender el compartimiento de una clase sin modificarla.

• Abierto a la extensión permite extender nuevas características con cambios solicitados.
• Cerrado a la modificación nos permite extender nuevas características de un módulo sin cambiar el código original del módulo.

Otra definición de OCP: Las unidades de software (clases, módulos, funciones u otros) deberían ser abiertas para la extensión pero cerradas para la modificación

Las clases utilizadas deben estar abiertas para extenderse y cerradas para modificarse.

• Nuevas características no alterarán el código ya existente.
• Permite utilizar extensiones de manera robusta.
• Permite extender el comportamiento de una clase, sin modificarla.

Nota: OCP se debe tener en cuenta al momento de desarrollar clases, librerías o frameworks. Así mismo, se aplicarán interfaces y abstracciones para su desarrollo.

Cualquier clase que sea hija de una clase padre debería poder usarse en lugar de su padre sin ningún comportamiento inesperado.

• Los objetos deben poder ser reemplazados por instancias de sus subtipos sin alterar el correcto funcionamiento del sistema.

Otra definición de LSP: Si en un programa utilizamos cierta clase, deberíamos poder usar cualquiera de sus subclases sin interferir en la funcionalidad del programa.

Las clases derivadas deben poder sustituirse por sus clases base.

• Reutilización del código.
• Buenas practicas de desarrollo a nivel de herencia.

Nota: Se hace uso de la herencia que permite a una clase heredar características, atributos o métodos de una clase padre.

Ninguna clase debe implementar interfaces con métodos que no utilice.

• No se deben implementar interfaces de propósito general.
• Se debe hacer uso de interfaces específicas según los métodos que se utilicen.

Otra definición de ISP: Crear interfaces específicas según el tipo de cliente.

Se deben crear interfaces de acuerdo a los métodos que se utilicen.

• Permiten refactorizar el desarrollo realizado.
• Brindan una buena estructura del código.
• Permiten tener un sistema desacoplado.

Nota: La creación de interfaces nos permiten desacoplar las unidades del software.

Depende de abstracciones, no de clases concretas.

• Las clases de alto nivel no deben depender de las clases de bajo nivel.
• Las clases de alto y bajo nivel deben depender de las abstracciones
• Las abstracciones no deben depender de los detalles.
• Los detalles deben depender de las abstracciones

• Permite reducir las dependencias entre los módulos del código.
• Permite a las clases alcanzar un bajo nivel de acoplamiento.
• Permite que una clase A no dependa del detalle de la implementación de otra clase.

Nota: Una clase no debe depender de una llamada a la base de datos, ya sea que consulte a una base de datos en MongoDB, SQL u otra forma de guardar los datos.