Por Thomas Robinson Rodríguez – Estudiante de la carrera de Ingeniería en Informática

Para todo aspirante a ingeniero en software, es necesario aprender nuevos conceptos durante toda su carrera profesional. Las tecnologías con las cuales el ser humano logra diseñar, construir e implementar programas para un sinfín de propósitos evolucionan día con día. Esto llega al punto de que los centros académicos no actualizan sus enseñanzas al mismo ritmo en que nuevas técnicas arrasan con la atención de los desarrolladores profesionales y del mercado laboral.

Si bien es cierto que los centros académicos nunca lograrán tener una precisión perfecta para preparar a los estudiantes ante el volátil mercado laboral, el nuevo aprendizaje puede apuntar a la enseñanza de principios contundentes en la programación que van a servir, no como simples términos a memorizar, sino como herramientas de vital importancia. Sin duda alguna, esto va a contribuir en el desarrollo de soluciones eficientes y creativas para que el estudiante recién egresado se desenvuelva de manera más fluida en su nuevo ambiente laboral y con su equipo de trabajo. A continuación, se van a introducir los principios S.O.L.I.D y por qué se recomienda usarlos en el área de programación orientada a objetos.

Principios

S: Single Responsibility Principle

La S representa el principio de responsabilidad única (Single Responsibility Principle, en inglés).  Consiste en asignar a cada clase una tarea como máximo. Esto logra facilitar la implementación de futuros cambios, evitando centralización innecesaria de responsabilidades dentro de una sola clase, lo cual conlleva a realizar una mayor cantidad de cambios para que el código no se vea afectado con errores.

O: Open-Closed Principle

Bajo el Principio Abierto-Cerrado (Open-Closed Principle): “Un módulo debe estar abierto a extensión, pero cerrado para modificación” (Martin, 2000, p.4). Esto se entiende bajo el hecho de dañar el programa, si se desea modificar una clase padre que fue utilizada por otras clases hijas. Al modificar la funcionalidad de la clase padre, las demás clases que hereden de ella van a verse alteradas y se deberán realizar cambios que consumirán más tiempo y recursos al programador, que debe dejar la clase padre intacta y extender funcionalidades a través de clases hijas.

L: Liskov Substitution Principle

El principio de sustitución de Liskov (Liskov Substitution Principle) propone que, si existe una propiedad “a” en una instancia “x” de un objeto tipo “T”, entonces debe de existir la misma propiedad, en una instancia “y” de un objeto tipo “S” que, al mismo tiempo, es hijo de “T”.  Esto se vuelve de máxima importancia para el programador al aplicar herencia de la manera óptima. Veamos un ejemplo: puede existir una clase Animal, que tenga como hijas Pez y Ave. Bajo el principio de Liskov, sería incorrecto colocar el método volar dentro de la clase Animal, ya que estaría heredando este método la clase Pez también. Evitar colocar propiedades específicas en objetos base es lo que el principio de Liskov propone.

I: Interface Segregation Principle

El principio de Segregación de Interfaz (por sus siglas en inglés ISP) busca descomponer el comportamiento de distintas clases en interfaces más pequeñas. Esto quiere decir que, por ejemplo, en vez de que métodos A, B, y C se encuentren en una sola interfaz X, puede descomponerse en tres interfaces: X (contiene el método A), Y (contiene el método B), Z (contiene el método C). Esto a su vez causa que, en el futuro, dos clases, P y Q, tengan la libertad de implementar cualquiera de estas tres interfaces sin verse obligadas a implementar las tres juntas,  promoviendo así la composición en vez de la herencia.

D:Dependency Inversion Principle

Finalmente, el principio de Inversión de Dependencias (Dependency Inversion Principle, en inglés) indica que en lugar de hacer que clases dependan de otras clases concretas, deberían depender de clases abstractas e interfaces. Esto a su vez brinda el beneficio de dividir con más profundidad el programa en tareas más pequeñas y mitigar el impacto de cambios que se realicen en el código, lo cual facilita el mantenimiento que se deba hacer en el programa a futuro.

Conclusión

Como se puede observar, los principios S.O.L.I.D le muestran al programador una vía distinta por la cual desarrollar sus programas, mostrándole que a través de la descentralización de responsabilidades en clases, extensibilidad de módulos, aplicación de herencia de una manera controlada, creación de pequeñas interfaces que permiten realizar implementaciones flexibles de métodos, y la implementación de dependencias de interfaces en vez de objetos concretos, sus soluciones llegan a tener un mejor ciclo de vida. De esta manera, puede evitar muchos dolores de cabeza a la hora de realizar cambios en el código fuente de sus aplicaciones.

 

MOXIE es el Canal de ULACIT (www.ulacit.ac.cr), producido por y para los estudiantes universitarios, en alianza con el medio periodístico independiente Delfino.cr, con el propósito de brindarles un espacio para generar y difundir sus ideas.  Se llama Moxie - que en inglés urbano significa tener la capacidad de enfrentar las dificultades con inteligencia, audacia y valentía - en honor a nuestros alumnos, cuyo “moxie” los caracteriza.

Referencias bibliográficas: