S.O.L.I.D. es un acrónimo que representa cinco principios básicos de la programación orientada a objetos y el diseño. Si se aplica correctamente, hace que el código sea más extensible, lógico y fácil de leer.
Cuando se crea software siguiendo un mal diseño, el código puede volverse inflexible y frágil. Pequeños cambios pueden provocar bugs. Por esta razón, debemos seguir los Principios SOLID.
Sus siglas representan:
S — Principio de responsabilidad única
O — Principio abierto cerrado
L — Principio de sustitución de Liskov
I — Principio de segregación de interfaz
D — Principio de inversión de dependencia
Principio de responsabilidad única
Este principio indica que cada clase debería de tener una sola responsabilidad, el objetivo es conseguir que nuestros componentes hagan una sola cosa y asegurarnos de que la hace bien.
Veamos un ejemplo rápido en el siguiente código:
Este componente no cumple el principio de responsabilidad única porque tiene más de una razón para cambiar; por ejemplo: alterar el header, agregar un nuevo componente a la aplicación o cada vez se modifique la tabla de la lista de usuarios.
Nuestra solución sería cambiar toda esta lógica a nuevos componentes de la siguiente manera:
Así, cuando se requiera cambiar algo en el header o en la lista de usuarios, se hará directamente en el componente correspondiente.
Principio abierto cerrado
Este principio nos dice que un componente debe quedar abierto para su extensión, pero cerrado para su modificación. Básicamente, que para añadir funcionalidades debemos agregar nuevo código, no modificar el existente que ya funciona.
Observando el componente UserList podemos notar que si se requiere mostrar a los usuarios en un formato diferente, se tendrá que modificar código, por lo cual no se estaría cumpliendo con este principio.
Ahora veremos un ejemplo del código refactorizado:
Se modificó el componente UserList de manera que está abierto para extenderlo, ya que renderiza a los hijos y está cerrado a modificación, porque todos los cambios se realizarán en diferentes componentes.
Ahora veamos un ejemplo de cómo se mostrarán los usuarios en la lista usando el nuevo componente.
Se amplió el funcionamiento de UserList, creando un nuevo componente y se puede obtener la información de los usuarios sin modificarlo.
Principio de sustitución de Liskov
Lo que nos dice este principio es que toda clase que es hija de de otra debe poder utilizarse como si fuera el mismo padre.
Principio de segregación de interfaz
Este principio nos dice que es mejor tener muchas clases pequeñas y especializadas que una enorme, ya que con una así acabas utilizando solo pequeñas partes en todo el código.
Veamos el siguiente ejemplo:
El componente UserTable renderiza al UserRow y pasa todo el objeto user como props. Podemos observar que el componente UserRow depende de todo el objeto user pero solo utiliza id y nombre. Si se realizara un test de este componente se tendría que hacer un mock de todo el user, de lo contrario el test fallará. La solución seria pasar solo las props que se vayan a utilizar en el componente.
Principio de inversión de dependencia
Este principio nos dice que los modelos de alto nivel no deberían depender de los módulos de bajo nivel. Ambos deberían depender de interfaces, es decir, se basa en la abstracción.
Las implementaciones concretas no deben depender de otras, sino de capas abstractas. Esto lo que nos permite es reducir el acople entre sistemas de software y no depender de si nuestra base de datos usa una tecnología u otra.
La comunicación entre los componentes del sistema es siempre mediante interfaces, esto nos permite tener libertad a la hora de decidir las implementaciones concretas de cada elemento. Así, por ejemplo, podríamos cambiar la base de datos de MongoDB a PostgreSQL sin afectar a ninguna parte del sistema.
Conclusión
Los principios SOLID son una herramienta que nos ayuda a escribir un código más limpio. Esto hay que tenerlo claro, ya que podemos aplicar este estándar de manera excesiva en sitios donde no haya necesidad.
Debemos aplicar estos principios si nos ayudan a escribir un mejor código, pero si utilizarlo nos lleva a complicar el sistema, deberíamos limitarnos a partes de él o ser más flexibles al implementarlo.
