EL PRINCIPIO DE SOLIDEZ (SOLID)

Cuando estamos aprendiendo a programar por primera vez, nuestra atención se centra únicamente en hacer que el sistema funcione como se espera, y no prestamos demasiada atención a los detalles estructurales o arquitectónicos que pueden ser relevantes en el futuro. Una vez que sabemos programar, nuestro interés ahora es que, además de que el sistema funcione, el código sea lo más limpio posible, ya que nos interesa poder modificar o añadir nuevo código en el futuro.

Pero ya que todos los sistemas crecen y aumenta el número de personas en el equipo, nos damos cuenta de que por mucho que nos esforcemos en tener todo en orden, hay un momento en el que sentimos que el sistema se descontrola y se convierte en un monstruo difícil de mantener y ampliar. Por eso, la forma correcta de crear sistemas es hacerlo pensando en términos de arquitectura. Entender que no estamos simplemente dando funciones al ordenador, sino que estamos creando un sistema complejo de instrucciones y requisitos.

Cuando hablamos de arquitectura de software, uno de sus pilares es el principio de diseño SOLID, definido por su creador Robert C. Martin en su libro Clean Architecture: "Los principios SOLID nos dicen cómo organizar nuestras funciones y estructuras de datos en clases, y cómo esas clases deben estar interconectadas"

La funcionalidad de este principio es permitirnos tener un código más fácil de entender, que tolere los cambios y cuyas partes puedan ser reutilizadas en algún otro sistema.

El nombre SOLID viene determinado por las iniciales de los siguientes principios:

- Principio de Responsabilidad Única: Un trozo de código debe hacer sólo una cosa.

**- Principio de apertura-cierre: las entidades de software deben estar abiertas a la ampliación, pero cerradas a la modificación.

- Principio de Sustitución de Liskov: Las funciones que utilizan punteros o referencias a clases base deben poder utilizar objetos de clases derivadas sin saberlo.

**- Principio de Segregación de la Interfaz: Muchas interfaces específicas del cliente son mejores que una interfaz de propósito general.

- Principio de Inversión de Dependencia: Depender de abstracciones, no de concreciones.

El propósito de este principio de diseño es guiarnos en la tarea de construir sistemas mucho más eficientes y al mismo tiempo con una estructura capaz de soportar tanto cambios en el comportamiento del sistema como en la forma en que las piezas del sistema se comunican entre sí, porque como dice su creador:

"Los buenos sistemas de software comienzan con un código limpio. Por un lado, si los ladrillos no están bien hechos, la arquitectura del edificio no importa mucho. Por otro lado, se puede hacer un lío importante con ladrillos bien hechos"