Ir al contenido principal

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.

Comentarios

Entradas populares de este blog

El Melange todavía corre

Ese era el estribillo de un capítulo de unas de mis series favoritas de la infancia, Meteoro o Speed Racer. En ese capítulo un auto “fantasma” el X-3, aparecía de imprevisto y dejaba a todos asombrados con su rendimiento y prestaciones y volvía a desaparecer. Traigo ese episodio a colación puesto que recientemente sostuve una amena charla con un querido amigo, en la que el me manifestaba como los Mainframes habían muerto, o mejor dicho, el concepto de la computación distribuida basada en Mainframes había desaparecido. Para variar, yo no estuve de acuerdo, y le dije que por el contrario, el modelo de computación basado en Mainframes está mas vigente que nunca. Estos fueron mis argumentos:

Primeros pasos con Camunda BPM – Modelando un Proceso BPMN 2.0

Tenemos entre manos la tercera publicación de nuestra serie sobre la Plataforma de BPM de Camunda .  El día de hoy vamos, por fin, a empezar a modelar o construir nuestro primer proceso sencillo en notación BPMN 2.0. Para ello vamos a usar el modelador o editor que ya hemos instalado en nuestra primera publicación , y vamos a guardarlo en la sección de recursos del proyecto Maven Java que configuramos en la segunda publicación . Así que, como ya es costumbre, manos a las sobras…

Como configurar jBPM para usar nuestra propia Base de Datos en un sólo paso

Llevo un buen rato trabajando con jBPM en su serie 6.x, y mi opinión sobre este producto en la versión mecionada no ha mejorado para nada. Es una herramienta plena de funciones y caracteristicas avanzadas, pero tambien está llena de Bugs y es realmente inestable, sobre todo en el ambiente de modelamiento.  Así mismo, debo decir que tiene una muy aceptable API REST y que el motor de procesos y la consecuente ejecución de los procesos es estable y bastante rápida. En esta publicación daré inicio a una serie de artículos que hablan sobre ciertas configuraciones comunes e importantes que se hacen con jBPM. Hoy iniciamos con la configuración de jBPM para que use nuestra base de datos favorita. Esto tiene sentido porque el producto viene con la base de datos H2 por omisión, la cual es excelente para pruebas y evaluaciones rápidas de la herramienta, pero es completamente inaceptable en un ambiente de desarrollo, QA o producción cualquiera. Así que manos a l