SOLID: Principios de diseño de software
El desarrollo de software es una actividad que requiere una excelente planeación para que el producto sea capaz de resolver las necesidades para las que fue creado; además, debe tener características importantes como escalabilidad, robustez y debe ser fácil de mantener y probar.
Existen principios de diseño establecidos para lograr que un programa sea lo más ágil posible, tales como SOLID. Acrónimo formado por las oraciones en inglés: Single Responsibility Principle, Open/Closed Principle, Liskov’s Principle of Substitution, Dependency-Inversion Principle e Interface-Segregation Principle. Estos principios fueron recabados por Robert C. Martin en su libro Agile Software Development: Principles Patterns and Practices; a continuación, se discuten cada uno de ellos.
S — Single Responsibility Principle (SRP)
El principio de responsabilidad única establece que una clase debe ser responsable de una sola funcionalidad, es decir, dicha clase solo tendría una razón para ser modificada.
Otros autores, para referirse al mismo caso, utilizan la definición de cohesión, y la describen como la relación funcional de los elementos de un módulo o clase. En esta relación, fijar la responsabilidad en cada clase permite cualquier modificación sobre la funcionalidad de clase, para así disminuir los errores. Entonces, existe una razón para modificar cada una de las clases porque son de responsabilidad única [Martin, 2014, p. 95].
Ejemplo: Un programa de calculadora simple consiste en dos partes: la interacción con el usuario (entrada y salida) y la lógica que computa las operaciones. Usando SRP, este programa debe contener al menos dos clases con responsabilidades fijas: interacción y cómputo.
O — Open/Closed Principle (OCP)
El principio de responsabilidad abierta-cerrada está pensado en los cambios de las entidades de software a lo largo de su ciclo de vida. “Las entidades deberían estar abiertas para extensiones, pero cerradas para modificaciones.”
Este principio intenta disminuir la rigidez del código, de tal forma que los cambios futuros solo sean adiciones de nuevo código y no cambios de código que ya funcione [Martin, 2014, p. 99].
Ejemplo: Una empresa de autos usados desarrolla software que modela atributos y métodos de autos. El OCP sugiere que cuando se agregue un auto nuevo con un comportamiento diferente (por ejemplo, estacionarse por sí solo), no se altere el código fuente de la clase base, sino que ese nuevo auto sea solo una adición aprovechando la abstracción.
L — Liskov Substitution Principle (LSP)
El principio de sustitución de Liskov establece que los subtipos podrían ser sustituidos por tipos de su base. Este principio está relacionado con las reglas diseñadas para la herencia en OOP. La premisa es sencilla: si se sustituye un objeto de una clase madre con la clase hija, este debería ser capaz de ejecutar los mismos métodos sin ningún problema [Martin, 2014, p. 111].
Ejemplo: Continuando con la empresa de autos, cualquier subclase que añada comportamiento a la clase madre seguirá teniendo un comportamiento similar a la clase que hereda. El principio estipula que cualquier instancia de subclase deberá ser capaz de llamar a los mismos métodos que la clase madre, es decir, compartir el mismo comportamiento.
D — Dependency-Inversion Principle (DIP)
El principio de inversión de dependencia establece que los módulos de alto nivel no deben depender de los módulos de bajo nivel y las abstracciones no deberían depender de los detalles. Dicho principio beneficia la reutilización o modificación de módulos de alto nivel sin afectar módulos de bajo nivel porque no hay una dependencia.
La dependencia en las abstracciones beneficia que las relaciones en el programa sean flexibles y no dependan de una clase en específico [Martin, 2014, p. 127].
Ejemplo: Si se diseña un programa de audio a partir de un tipo definido de sonido con intervalos de frecuencias, decibeles y número de bocinas, se estaría dependiendo del detalle de un caso en particular. Lo mejor es pensar en la abstracción del equipo y considerar todos los posibles casos, para que cualquier cambio de alto nivel sea independiente de las características de bajo nivel.
I — Interface Segregation Principle (ISP)
El principio de segregación de interfaz establece que un módulo no debería estar forzado a depender de métodos que no se usan y sugiere la creación de interfaces o clases específicas para determinados módulos. Es una manera de afrontar las desventajas de interfaces enormes, es decir, interfaces no cohesivas y basadas en abstracción en lugar de instancias [Martin, 2014, p. 135].
Ejemplo: Un visualizador de imágenes médicas tiene interacción entre distintos módulos: la clase Paciente y la clase Scheduler. La interfaz del médico debe contener únicamente los métodos que sí utiliza de cada clase, no todo su contenido. Puede ver edad, peso y altura, pero no puede modificar dichos valores; puede realizar operaciones sobre la imagen del estudio, pero no puede modificar el procesamiento de la misma.
Conclusión
Los principios SOLID son una referencia muy importante al momento del diseño del software. El objetivo es lograr un código de programación orientado a objetos con la capacidad de ser escalable, estable, flexible y mantenible.
Así mismo, los principios están basados en los conceptos más importantes de la programación orientada a objetos, tales como modificadores, herencia, encapsulación, polimorfismo, atributos y métodos. Entonces, llevar buenas prácticas con base en la metodología SOLID, es sinónimo de comprender de forma lógica y eficiente la programación orientada a objetos.
Referencias
- Martin Robert C. 2014. Agile Software Development: Principles Patterns and Practices. 1st ed. Pearson new international ed. Essex (U.K.): Pearson.