Principios SOLID

En los primeros tiempos del desarrollo de software, los desarrolladores solían escribir condigo con lenguajes de programación procedimentales. En la programación por procedimientos, los programas siguen un orden desde arriba hasta abajo y la lógica está incluida dentro de funciones.

Nuevos estilos de programación, como la programación modular o estructural, emergieron cuando los desarrolladores se dieron cuenta de que la programación de procedimientos  no proveía del deseado nivel de abstracción,  mantenibilidad y reusabilidad.

La comunidad de desarrolladores creó una serie de patrones de diseño y prácticas recomendadas para incrementar el nivel de abstracción y reusabilidad de la programación por procedimientos, pero algunas de esas guías requerían un cierto nivel de experiencia. Con el propósito de facilitar la asunción de estas guías, surgió un nuevo estilo de programación conocido como programación orientada a objetos.

Los desarrolladores rápidamente se dieron cuenta de algunos muchos errores comunes que suelen ocurrir en la programación orientada a objetos e inventaron cinco reglas que todo desarrollador orientado a objetos debía seguir para crear un sistema que fuera fácil de mantener y escalable a través del tiempo. Estas cinco reglas son conocidas como los principios SOLID. SOLID es un acrónimo introducido por Michael Feather a partir de los siguientes principios:

Single responsability prínciple (SRC) – Responsabilidad simple

Este principio establece que un componente del software(función, clase o módulo) debe estar centrado en una única tarea (tener solo una responsabilidad)

Open/Close prínciple (OCP )- Abierto/cerrado

Establece que el software debe ser diseñado pensando en el crecimiento de la aplicación, con la incorporación de nuevo código, pero este crecimiento debe requerir el menor número de cambios en el código existente. Abierto a lo nuevo, cerrado para lo viejo.

Liskov substitution principle (LSP) – Sustitución de Liskov

Establece que deberíamos ser capaz de sustituir una clase por otra siempre que ambas clases implementen la misma interface. Después de la sustitución, ningún otro cambia será necesario para que el programa continúe funcionando como lo hacia originalmente.

Interface segregation principle (ISP) – Segregación de interface

Establece que deberíamos descomponer las  interfaces grandes y de propósito general en otras más pequeñas y específicas de forma que los clientes que las usen solo tengan la necesidad de conocer los métodos en los que están interesados.

Dependency inversión principle (DIP)- Inversión de dependencias

Las entidades deben depender de las abstracciones (interfaces) en oposición a la dependencias de concreciones (clases)