Cuando aprendemos a programar por primera vez, nuestra atención se centra únicamente en hacer que la funcionalidad del sistema funcione según lo esperado, y no prestamos demasiada atención a los detalles estructurales o arquitectónicos que pueden ser relevantes en el futuro. Una vez que sabemos cómo programar, nuestro interés ahora es que, además de hacer que el sistema funcione, el código sea lo más limpio posible, ya que nos interesa poder modificar o agregar nuevo código en el futuro.
Pero todos los sistemas crecen y el número de personas en el equipo aumenta, nos damos cuenta de que, por mucho que intentemos tener todo en orden, hay un momento en el que sentimos que el sistema se sale de control y se convierte en un monstruo difícil de mantener y extender. Es por eso que la forma correcta de crear sistemas es hacerlo pensando en términos de arquitectura. Comprendamos que no estamos simplemente dando funciones a la computadora, 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 que sea más fácil de entender, pueda tolerar cambios y cuyas partes puedan ser reutilizadas en algún otro sistema.
El nombre SOLID está determinado por las iniciales de los siguientes principios:
Principio de Responsabilidad Única: Un fragmento de código debe hacer solo una cosa.
Principio Abierto/Cerrado: Las entidades de software deben estar abiertas para su extensión pero cerradas para su 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 Interfaces: 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 de manera mucho más eficiente 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, puedes hacer un lío sustancial con ladrillos bien hechos."