Solid, cinco principios básicos de diseño

Solid es un acrónimo inventado por Robert C.Martin para establecer los cinco principios básicos de la programación orientada a objetos y diseño. Este acrónimo tiene bastante relación con los patrones de diseño, en especial, con la alta cohesión y el bajo acoplamiento.

El objetivo de su implementación es poder escribir un código de mayor calidad, creando un sistema fácil de mantener, rehusar, y extender en el tiempo.

Principio de responsabilidad única

Este principio menciona que una clase o módulo debe tener una única responsabilidad.

La cual es definida como una razón para cambiar

Cumpliendo este principio te aseguras que tu clase o módulo tenga una cohesión alta, lo que significa que tu clase no hace más de lo que debería hacer.

Principio abierto-cerrado

Este principio habla sobre como crear clases extensibles sin necesidad de entrar al código fuente a modificarlo. Es decir, el diseño debe ser abierto para poderse extender pero cerrado para poderse modificar.

Aplicando este principio conseguirás un acople más relajado, mejoraras la lectura y finalmente, reducirás el riesgo de romper alguna funcionalidad ya existente.

Principio de sustitución de Liskov

Este principio nos dice que si en alguna parte de nuestro código estamos usando una clase, y esta clase es extendida, tenemos que poder utilizar cualquiera de las clases hijas y que el programa siga siendo válido.

Esto nos obliga a asegurarnos de que cuando extendemos una clase no estamos alterando el comportamiento de la padre.

Principio de segregación de la interfaz

Este principio nos dice que ninguna clase debería depender de métodos que no usa.

Por tanto, cuando creemos interfaces que definan comportamientos, es importante estar seguros de que todas las clases que implementen esas interfaces vayan a necesitar y ser capaces de agregar comportamientos a todos los métodos.

En caso contrario, es mejor tener varias interfaces más pequeñas.

Principio de inversión de la dependencia

La definición que suelen dar es:

  • 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.

Este principio es una técnica básica, y será el que más presente tengas en tu día a día si quieres hacer que tu código sea testable y mantenible.

Gracias al principio de inversión de dependencias, podemos hacer que el código que es el núcleo de nuestra aplicación no dependa de los detalles de implementación