Seguramente habrás escuchado a los principios SOLID, y si no aquí los conocerás, es importante conocerlos y posteriormente aplicarlos básicamente por dos motivos, el primero es porque es muy común que te pregunten por estos principios en las entrevistas técnicas para desarrollador y el no saber responder a esta pregunta te dejaría muy mal parado ya que se supone que un desarrollador debe al menos conocerlos y aplicarlos aunque sea alguno de estos principios.

Entonces si puedes aprenderlos ¿porqué no hacerlo? así tendrás una ventaja competitiva respecto a la docena restante de programadores que pugnan también por el mismo puesto que tú. La segunda razón es porque los tendrás que usar en tu día a día como desarrollador, por tu bien, ya que tu código se esperaría que fuese más mantenible, organizado, legible y escalable, eso es invaluable con el tiempo y te hará más fácil tu trabajo a mediano plazo, además que estarás cumpliendo con un estándar de calidad mínimo en la industria del software y en la empresa misma, todo esto te hará más valioso y deseable como desarrollador para las empresas y eso significa un cheque más grande a fin de mes ¡provecho!.

En síntesis SOLID es un acrónimo nemotécnico de las primeras letras de los 5 principios que veremos a continuación, fueron propuestos por Robert Martin en el 2000 (aquí recomiendo un libro de él), estos principios son guías y buenas prácticas a seguir para obtener un código de calidad, sin embargo no deben ser tomadas como escritas en piedra y aplicarlos a rajatabla o forzar su aplicación en nuestro código porque hay ocasiones en los que podemos prescindir de alguno de sus principios por practicidad y que si forzamos aplicarlos en estos casos haremos más daño que bien a nuestro código haciéndolo más confuso, intrincado e innecesariamente complejo, por eso tomar con criterio estos principios en nuestros proyectos y buscar siempre el equilibrio entre practicidad/calidad en nuestro código 😉 sin embargo si los que más saben lo usan por algo será, así que a practicar los principios SOLID!

Single Responsibility Principle (SRP)

Este principio postula que una clase debe tener sólo una razón para existir, con esto evitamos la mala práctica conocida como la "clase dios" o "super clase" en la cual queremos que una clase haga más de una cosa, y pensamos que esto es bueno, que la clase haga de todo y tratamos de hacerla todo poderosa y que con parámetros en sus métodos hagan diversas funcionalidades, y hasta puede que nos sintamos orgullosos de ello 😁 sin embargo estamos cayendo en un vicio.

Un ejemplo de cómo aplicar este principio es evitar hacer consultas SQL desde una vista, ya que estaríamos añadiendo una responsabilidad de acceso a datos a una clase cuya responsabilidad primaria es la de mostrar controles e interfaces al usuario.

Open Close Principle (OCP)

Este principio dice que nuestro código debe ser abierto a la extensión y cerrado a la modificación, esto lo logramos aplicando el polimorfismo y la abstracción. En buen cristiano esto significa que si a un bloque de nuestro código por ejemplo un método le queremos añadir una nueva funcionalidad esta debe añadirse mediante agregarla en nuestro código no mediante cambiar todo el código existente a la ligera, esto nos obliga a manejar nuestras funcionalidades con código modular por llamarlo de alguna manera y no estar sobre-escribiéndolo o parchándolo si queremos añadir una funcionalidad o feature nuevo.

Liskov Substitution Principle (LSP)

Este principio se define así: "Si S es un subtipo de T, las apariciones de tipo T en un programa pueden ser reemplazadas por otra de tipo S sin que el funcionamiento del programa se vea alterado". Esto quiere decir que sólo debemos derivar o heredar de una clase para añadir funcionalidades, nunca para modificar lo existente, o en otras palabras una clase que hereda de otra puede usarse como su padre sin necesidad de conocer las diferencias entre ellas.

Interface Segregation Principle (ISP)

En el caso de este principio, no debemos dar más información de la necesaria a los módulos para funcionar. Esto se logra mediante separar las interfaces. Un ejemplo clásico de este principio es el de la transacción de un cajero automático postulado en el libro "Desarrollo de Software Ágil: Principios, patrones y prácticas" de Robert Martin, este ejemplo trata sobre la interfaz de usuario para un cajero automático, que maneja todas las peticiones (como consulta de saldos o retiros), y cómo esta interfaz necesita ser segregada en interfaces más específicas y más concretas.

Dependency Inversion Principle (DIP)

Este principio nos dice que debemos reducir la dependencia entre los módulos de nuestra aplicación, los módulos no deben ser los encargados de crear los objetos con los que trabajan sino que deben ser creados por alguien más y pasárselos a un constructor para que los use cuando quiera. Este principio está muy relacionado con la buena práctica de Inyección de dependencias que puedes aprender más en esta entrada anterior.

En una entrada posterior haremos un taller de código poniendo ejemplos reales por cada uno de estos 5 principios, de momento investiga y aprende los conceptos aquí repasados estimado lector, y ya sabes comparte si te aportó valor esta entrada crack! 😊