miércoles, 17 de enero de 2018

Principios SOLID en tu día a día

Durante los primeros años de mi carrera profesional, tanto en la facultad como en el trabajo, me encontré en algunas ocasiones con las palabras “buenas prácticas” o “principios de desarrollo”. La primera vez que las oí, pensé que eran consejos precisos sobre cómo afrontar un desarrollo en particular, es decir, para un caso concreto. Uno también podría pensar o asociar la idea a un tema que estudiamos en alguna materia de diseño de sistemas: los patrones; pero en este caso no, ya que sabemos que estos son soluciones reutilizables para problemas puntuales. Entonces, ¿a qué se referían con estos con términos?

Cuando comencé mi primer trabajo como programador, me encontré frente a un proyecto de mantenimiento y mejoras donde hallé documentos de buenas prácticas o estándares de desarrollo del proyecto y nuevamente me crucé con estas palabras.

Finalmente, gracias a un estudio que realicé sobre los principios SOLID, logré entender de que se tratan. ¿Y qué son? Son justamente eso, buenas prácticas o consejos que descienden de la misma esencia que plantea y engloba el paradigma de objetos. Esto nos lleva a tener en cuenta los conceptos que caracterizan al modelo, es decir, abstracción, composición, encapsulamiento, herencia y polimorfismo, que son los que nos permitirán llegar a una solución con buenas prácticas.

Si queremos demostrar que utilizamos estos principios en nuestro día a día, debemos explicar brevemente cómo están compuestos.

La sigla SOLID (por sus iniciales en inglés) proviene de una serie de principios:
  • Single Responsability Principle
  • Open Close Principle
  • Liskov Substitution Principle
  • Interface Segregation Principle
  • Dependency Inversion Principle

Single Responsability Principle o Principio de Responsabilidad Única: establece que una clase debe tener una única responsabilidad. Esto quiere decir que las clases definidas en nuestro código fuente deben ser cohesivas, tener un único fin para el cual fueron definidas y nada más.

Open Close Principle o Principio Abierto Cerrado: aconseja que una clase debe permitir la extensión y prohibir una modificación. Si se define de una forma es por una razón y debe estar dedicada a lo que se definió.

Liskov Substitution Principle o Principio de Sustitución Liskov: establece que los subtipos deben ser capaces de ser sustituibles por sus tipos base. En pocas palabras, los programas deben referenciar a las abstracciones y no a las implementaciones.

Interface Segregation Principle o Principio de Segregación en Interfaces: establece que los implementadores de interfaces no deben estar obligados a implementar métodos que no usan, es decir, que deben ser cohesivas.

Dependency Inversion Principle o Principio de Dependencia en Inversión: aconseja que las abstracciones no deben depender de los detalles, sino viceversa, lo que significa que las dependencias entre clases deben cambiarse por abstracciones.

Y ahora es donde surge la pregunta ¿fui capaz de aplicar un principio sin conocerlo? A lo cual respondo, , es muy posible.

Estos principios le muestran perfectamente a una persona que recién entra en el mundo de la programación, (aprendiendo de forma autodidacta, con un profesor o de forma virtual), cómo se manifiestan los distintos tipos de paradigmas y lo orientan en la selección personal del primer lenguaje a aprender.

Los principios SOLID se encuentran tan presentes en nuestro trabajo, que muchas veces los utilizamos sin darnos cuenta.

Si son de los que modularizan absolutamente todo en la solución del proyecto, entonces el primer principio lo tienen en el bolsillo. Permitir que una clase tenga una única responsabilidad se debe a la sencillez del programador, mientras menos presión se ejerce en un funcionamiento, menos margen de error se maneja.

Ahora bien, ¿son prácticas o principios obligatorios? No, claro que no lo son. Son consejos que podemos tomar o dejar. Siempre dependemos del contexto en el que estamos; no por querer trabajar con buenas prácticas deberíamos refactorizar una aplicación entera para poder aplicarlos. Muchas veces estamos restringidos por los requerimientos y por uno de los factores más críticos, el tiempo.

En conclusión, es importante conocerlos, entenderlos y dependiendo del contexto en el que trabajemos, evaluar la factibilidad de aplicarlos.

Autor: 
Anibal Ezequiel Montalti
Desarrollador .NET