SOLID Princples

Uno de los conceptos que más he logrado escuchar a lo largo de mi camino como Ingeniero de software -que quiero aclarar que no es mucho puesto que aún no me convierto oficialmente en uno- es el de los principios SOLID y el impacto que estos tienen al momento de planificar, crear y mantener tanto productos digitales como corporaciones y hasta industrias completas. En el texto Understanding the SOLID principles por Edward Guiness resumido en la página del profesor, Ariel Ortiz, el lector es introducido a este acrónimo por medio de un resumen de cada uno de los principios que lo conforman:

Single Responsability Principle: una clase solamente debería de tener una y solo una responsabilidad. Es decir, hará un solo trabajo dentro del código. Haciendo así, que, entonces, sea más sencillo modificar un solo comportamiento no anidado. 

Open/Closed Principle: un componente se abre para ser extendido pero es cerrado para ser modificado. Es decir, una entidad puede permitirse evolucionar siempre y cuando no se modifique su código de origen. 

Liskov Substitution Principle: una entidad puede ser reemplazada por otra, siempre y cuando pertenezca a la misma subclase. Es decir, un objeto de una superclase T puede ser intercambiable con una subclase S sin romper la aplicación.

Interface Segregation Principle: un componente no debería de ser forzado a tener responsabilidades o funcionalidades que jamás le servirán en su contexto. Es decir, es más útil cuando no depende de los métodos de interfaces que no usará. 

Dependency Inversion Principle: la jerarquía de un componente es importante, pero más importante cuando éste se basa en lo abstracto y no en lo concreto. Es decir, éste establece que los módulos de alta jerarquía no deberían de depender de los de baja jerarquía, y, a su vez, estos no deben ser dependientes a detalles concretos, sino en abstracciones del problema a resolver.

Después de la breve noción de cada uno de estos, y, para darle fin a esta entrada, la razón por la que surgen y han tenido tanto impacto en la industria del software es la que ha dado lugar a este último en primer lugar: simplificar el trabajo, haciéndolo a la vez más eficiente y menos dependiente a procesos complicados. Es decir, se nos menciona en este texto que SOLID no es más que la solución más popular al problema de conexiones estrictas entre nuestro código, haciendo que, en conjunto, cada uno de los atributos de ella logren hacer que el mantenimiento y escalabilidad sea más sencilla de llevar a cabo y, por ende, los proyectos futuros tengan un mejor y más prolongado impacto.

Comentarios

Entradas populares de este blog

Los microservicios

Las corporaciones necesitan de arquitectos más que el software