En esta, mi primera entrada en este reconocido blog, estaré tocando el tema de los principios SOLID, para tener los conceptos más claros, ya que es una de las preguntas más comunes en las entrevistas de trabajo para desarrolladores de software y además te permitirá tener una buena base en la programación orientada a objetos. Ya he escrito acerca de este tema y he recibido feedback, aprovechando eso trataré de manejar el tema con palabras sencillas y prácticas para una comprensión rápida del tema 😉.
El aprender estos principios SOLID te supondrá una ventaja competitiva respecto a la docena de programadores que pugnan también por el mismo puesto que tú y una vez dentro del trabajo te ayudará a que tu código sea 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 de la empresa misma, todo esto te hará más valioso y deseable como desarrollador para las empresas y eso significa que puedes tentar un cheque más grande a fin de mes ¡provecho!.
La palabra SOLID es un acrónimo de las primeras letras de los 5 principios que veremos a continuación, fueron propuestos por Robert Martin en el 2000 (aquí recomiendo entre otros un libro de él), estos principios son guías y buenas prácticas a seguir para obtener un código de calidad, aun teniendo en cuenta esto, no debemos 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.
Hay que tener en cuenta que si forzamos la aplicación de estos principios SOLID podríamos hacer más mal que bien a nuestro código porque resultaría más confuso, intrincado e innecesariamente complejo, lo que hay que buscar es el equilibrio entre practicidad/calidad en nuestro código. Hazlo con buenas prácticas, hazlo simple, hazlo efectivo.
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. Que tu código y su estructura sea tan SÓLIDOS como una montaña!
Pues bien, de momento lo que te toca a ti es investigar y repasar los conceptos aquí repasados estimado lector, pero sobre todo ponerlos en práctica, y ya sabes comparte si te aportó valor esta entrada crack! 💪😊