Introdución a los Principios SOLID

SOLID es un acrónimo para una serie de principios básicos, 5 en total,  de la programación orientada a objetos (POO) y el diseño orientado a objetos (OOD) inventado por Robert C. Martin. Estos principios tienen relación con algunos patrones de diseño.

Muchos creen que el objetivo de la arquitectura de software, los patrones de diseño y los principios SOLID es programar más rápido. Pero no. La verdad es que el objetivo real es facilitar el mantenimiento de los grandes proyectos de software. Como norma el mantenimiento consume muchos recursos de los destinados a los proyectos de software, hasta un promedio de 77%, por lo que los ahorros en esfuerzos en esta área son cruciales para facilitar el sostenimiento de una plataforma de software o de soluciones de software cualquiera.

En forma general estos principios son los que a continuación se detallan…

Responsabilidad Simple (Single Responsibility)

Zapatero a su zapato y pastelero a sus pasteles, dice el dicho popular, y en la POO es también una realidad deseable.

Este principio establece que las clases y sus métodos deben ser atómicos en su funcionalidad.

En otras palabras. Cada clase debe ser diseñada con un propósito u objetivo específico, y cada uno de los métodos de esa clase debe realizar una sola tarea, y hacerla bien.

Muchas veces nos encontramos trabajando en una clase, y tenemos la necesidad de escribir un método que no está directamente relacionado con esa clase y su propósito; es allí cuando nos vemos tentados a decir “bueno, para que voy a crear otra clase si ya estoy aquí…. Seguro que esto no lo vuelvo a necesitar mas, y si llego a necesitarlo seguro recordare donde buscarlo”.

Y es así como terminamos con una clase que maneja conexiones de red que tiene métodos para formatear cadenas caracteres, por ejemplo.

Esto a la larga resulta en una dificultad mayor para administrar las clases y sus métodos, dificultando la administración general del sistema.

Abierto/Cerrado (Open Closed)

Lo que funciona NO lo arregles. Otra verdad cotidiana que tiene su contraparte en el mundo de la POO. Este principio se le atribuye a Bertrand Meyer, y establece que las clases y los programas o sistemas deben estar Abiertos a la Ampliación pero Cerrados a la Modificación.

En otras palabras, debemos poder extender las capacidades de un sistema sin tener la necesidad de modificar o cambiar las otras partes ya existentes. Podemos incorporar nuevas clases y actualizar configuraciones, pero no deberíamos tener que modificar las clases ya existentes.

Esto por lo general se logra usando patrones de diseño, tales como lo son comando y estrategia, Factory, etc.

Así mismo hace uso de otro principio de diseño que establece que hay que favorecer la composición y la agregación antes que la herencia de clases.

Por otro lado también se relaciona con el principio que establece que hay que programar y diseñar para una Abstracción (Interface, Clase Abstracta, etc.) y no para una implementación concreta.

En general se persigue que las clases encapsulen comportamiento, y que este comportamiento, por lo tanto, pueda ser reemplazado cambiando las implementaciones, incluso agregando nuevas, pero sin modificar las interfaces o contrato de comunicación de las diversas clases que conforman la solución de software. De esta forma nuestros sistemas pueden ser ampliados sin tener que ser modificados.

Sustitución Liskov (Liskov substitution)

Este principio fue establecido por Barbara Liskov y habla de la importancia de crear todas las clases derivadas para que también puedan ser tratadas como la propia clase base.

En otras palabras, si todo funciona con la clase base, debería seguir funcionando si la cambiamos por una subclase.

El problema es que en muchas ocasiones la herencia trae consigo comportamientos inesperados, sobre todo cuando se mantienen largas jerarquías de herencia (muchos niveles) y se sobre escriben muchos métodos.

Un ejemplo es la clase Cuadrado. Matemáticamente hablando un Cuadrado es un caso especial de los Rectángulos, sólo que tiene ambos lados iguales, por lo que podemos decir que un Cuadrado ES-UN Rectángulo. Pero qué ocurre con el método setWidth (establecerAncho) del Cuadrado, si alguien lo implementa decidiendo modificar también el alto (debido a que deben ser iguales) dentro de este método. Al usar la sub clase, clase derivada, Cuadrado en lugar de un Rectángulo, voy a obtener comportamientos no esperados al momento de trabajar con sus métodos.

Puede parecer engañosamente simple resolver estos conflictos o tenerlos en cuenta, pero por lo general es difícil verlos al momento del diseño.

Segregación de interfaces (Interface segregation)

Robert C. Martin estableció que las interfaces (y las clases abstractas) deben definir un conjunto de métodos estrechamente relacionados a un objetivo. En otras palabras, es mejor tener varias interfaces pequeñas, pero con métodos específicos a una tarea determinada, que una sola gran interface con un montón de métodos que, seguramente, no serán requeridos todos juntos en algún momento.

Tener interfaces con un gran número de métodos cuando sólo se precisan algunos de ellos, lleva a tener implementaciones de métodos Dummy o tontos, vacíos, cuya existencia solo se justifica para dar cuerpo a todos los métodos de la interface.

Inversión de dependencias (Dependency inversion)

La Inversión de Dependencias establece que si una clase depende de otra, esta dependencia debe venir orientada o dada por una dependencia de interfaces y no de una clase concreta.

Este concepto también se relaciona con la Inyección de dependencias y la dependencia de módulos, la primera implica la inyección de una implementación de una clase sin tener que hacer new(); el segundo nos habla sobre las distintas capas de un sistema, donde los diversos módulos internos no deberían depender de elementos más externos o internos a ellos mismos. Por ejemplo, un módulo de la capa de negocios no debería tener dependencias con la capa de front-end o pantallas (formularios, etc.) de la aplicación.

Como ven, son principios relativos al diseño y construcción de sistemas orientados a objeto. Les dejo un enlace a este genial artículo sobre los principios SOLID.