Principios de programación SOLID

Los principios de programación SOLID son una excelente guía para mejorar tus habilidades de programación. Recuerda que los patrones y los principios de programación son solo guías, no debes seguirlos al pie de la letra, lo importante es que los entiendas y eso te dé herramientas para poder evaluar cada caso de uso.
Hablemos un poco de cada uno de estos principios:

Single Responsibility

Principio de responsabilidad única. Este principio es probablemente uno de los más sencillos para comenzar y se refiere a que cada clase debe tener una responsabilidad única y bien definida. Por ejemplo, si necesitamos crear un endpoint que recibe un request, validar la autenticación, consultar la base de datos y regresar una respuesta, deberíamos tratar de hacerlo en múltiples clases y no crear una sola clase que cargue con todas las responsabilidades.

Open-Close Principle

Este principio nos dice que una clase debe estar abierta para su extensión pero cerrada para su modificación, esto normalmente lo podemos lograr usando herencia o interfaces, por ejemplo si tenemos una sección de nuestra app que recibe un módulo de autenticación que funciona basado en email/password pero queremos que ahora también funcione con un token jwt, en lugar de buscar modificar las clases actuales, podríamos buscar extender la funcionalidad mediante herencia o interfaces.

Liskov Substitution

Este principio nos dice que teniendo cualquier abstracción, todas las clases derivadas deben poder funcionar correctamente, es decir, si tenemos una clase que recibe alguna clase Abstracta o una Interfaz, cualquier elemento derivado que inyectamos debe poder funcionar dentro de ella.

Interface Segregation Principle

Este principio nos dice que no debemos forzar clases a implementar elementos o características que no necesitan, por ejemplo si tenemos una interfaz que nos obliga a implementar 2 funciones diferentes, pero tenemos un objeto que solo utilizará una de esas funciones, probablemente lo más adecuado será dividir la interfaz en 2 interfaces con un solo método, y dejar que los objetos solo implementen los métodos que realmente van a necesitar.

Dependency Inversion Principle

Este principio habla de cómo podemos desacoplar nuestro código, nos dice que no debemos crear clases con dependencias muy estrictas, por ejemplo, si tenemos una clase A y dentro del constructor creamos la instancia de una clase B. Podríamos decir que la clase A está muy acoplada con la clase B por que una depende directamente de la otra y por lo tanto será más complicado mantenerlas en caso de que necesitemos modificar su funcionamiento, por otro lado si inyectamos un objeto de la clase B en lugar de crearlo, estamos dividiendo un poco más el control al dejar la creación de la clase B fuera de nuestro constructor, pero mejor aún, si en lugar de que nuestro método reciba la clase B recibe una abstracción superior, como una clase abstracta o una interfaz, pues estamos desacoplando aún más nuestro código y serás capaz de intercambiar objetos externos a esta clase sin que por ello se afecte el funcionamiento de la misma, en este momento tendrás bajo acoplamiento y una mejor estructura en tu proyecto.

Estos principios de programación, así como los patrones de diseño, son herramientas muy poderosas que te ayudarán a mejorar como desarrollador cada día. Sin embargo, recuerda que nunca debes seguir reglas ciegamente, sigue aprendiendo y sigue practicando para que logres conocerlas a fondo y así tener la capacidad de realmente aplicar las cosas que necesitas en el momento en el que las necesitas.

¡Nunca pares de aprender!