Qué son y cuáles son los principios SOLID

POST

Más sobre el tema.

Osvaldo Galván

Osvaldo Galván

Principios SOLID
Cómo aplicar el buen diseño de softwarre

Los principios SOLID son 5 principios básicos de diseño de software aplicados a la programación orientada a objetos, creados por Robert C. Martin.

El objetivo de los principios SOLID es diseñar y desarrollar software de calidad a través de la aplicación de patrones de diseño de código limpio.

La aplicación conjunta de estos 5 los principios SOLID permite desarrollar software escrito en código limpio, fácil de entender, mantener y testear.

Estos principios guardan cierta relación con patrones de diseño, en especial, con la alta cohesión y el bajo acoplamiento.

Los principios SOLID en conjunto con el desarrollo basado en pruebas (TDD) deben formar parte integral de una buena estrategia de desarrollo de software.

Los principio SOLID son:

  • SRP: Single Resposability Principle
  • OCP: Open/Closed Principle
  • LSP: Liskov Substitution Principle.
  • ISP: Interfaze Segregation Principle.
  • DIP: Dependency Inversion Principle.

SRP: Single Resposability Principle

Principio de responsabilidad única: Un objeto debe realizar una sola cosa, es decir, cada objeto en el sistema debe tener una simple responsabilidad, un propósito único y concreto.

De la misma forma, cada objeto se permite recibir ciertos datos, procesarlos y regresar una salida única y especifica.

Una clase debe tener una única razón para cambiar

En términos prácticos, al desarrollar software se tiene que evitar construir clases monolíticas con múltiples funciones y diferentes funcionalidades.

Sin embargo, no confundir el hecho de tener muchas pequeñas clases, haciendo pequeñas cosas. Por el contrario, este principio se enfoca en tener clases, con uno a varios métodos, que se relacione en cuanto a su funcionalidad.

En otras palabras, este principio aplica para construir clases que agrupen comportamientos específicos dentro del sistema.

Por ejemplo, no es lo mismo construir dos clases, la primera con un método que cálculo el número de días entre dos fechas dadas. La segunda con otro método que calcule el periodo en meses entre dos fechas dadas.

Por el contrario, y con el fin de respetar el principio, podemos construir una clase que comparta la misma responsabilidad, en el ejemplo anterior de las fechas, podemos tener una clase que realice cálculos sobre fechas.

La responsabilidad de la clase dependerá del contexto del sistema. Dependiendo el sistema, el contexto pude cambiar.

OCP: Open/Closed Principle

Principio Abierto/Cerrado: Una entidad de software (clase, modulo, función) debería estar abierta para extenderse, pero cerrada para modificarse.

En otras palabras, las entidades de software deben tener la capacidad de poder extenderse por otras entidades SIN la necesidad de modificarla internamente.

Suele pasar que en ocasiones intentas implementar un método de otra clase, y descubres, que para poder implementarlo requieres modificar el código original.

Una clase debe estar abierta a la extensión y cerrada a la modificación

Cumplir con este principio representa un reto interesante, de origen, no sabemos, y no podemos suponer, que otras funcionalidades se requieran desarrollar.

Es un hecho, el cambio existe y es constante. Por esta razón, se recomienda desarrollar software que pueda cambiar con facilidad.

No intentemos anticiparnos y desarrollar funciones que quizás nunca se usaran, por el contrario, diseñemos sistemas usando patrones para modelar y minimizar el impacto del cambio

Un sistema mal diseñado se convierte fácilmente en una aplicación rígida, impredecible y poco reutilizable.

Usando la herencia y el polimorfismo podemos cumplir con este principio. Considera que ambos objetos tendrán que implementar la misma interfaz.

LSP: Liskov Substitution Principle.

Principio de sustitución Liskov: Una subclase puede ser remplazada por otra subclase sin afectar el comportamiento del sistema.

En otras palabras, el comportamiento de las subclases tiene que seguir siendo compatible con el comportamiento de la clase padre.

Cada clase que se hereda de otra clase podrá ser usada como clase padre sin la necesidad de conocer a su antecesor. Esto obliga, a no modificar el comportamiento de padre al extender una clase.

Define una jerarquía específica de clases que no afecta el comportamiento del sistema sin importar si se implementa la clase padre o una de sus subclases.

Este principio fue acuñado por Bárbara Lisvoc, de ahí su nombre. Este principio contiene una serie de pautas que se deben cumplir, si o si, para cumplir con la aplicación del principio.

De igual forma, este principio se enfoca en crear jerarquías de herencia para que los clientes que extiendan cierta funcionalidad puedan usar de forma confiable la clase padre o sus subclases sin que esto afecte el comportamiento del sistema.

El principio Lisvoc establece reglas para cumplir con su aplicación. Estas pueden agruparse en dos:

  • Reglas de contrato: Definen la expectativa de la clase, qué y cómo esperamos que las subclases se comporten.
  • Reglas de varianza Definen los tipos de datos, tanto los de entrada como salida, que tipos de datos son permitidos como entrada y qué tipo de dato será devueltos.

En resumen, la aplicación correcta de este principio permite que una parte del sistema haga uso, indistintamente, de una clase o sus subclases sin que esto afecte el comportamiento del sistema.

ISP: Interfaze Segregation Principle.

Principio de segregación de interfaces: Las clases que implementen una interfaz o una clase abstracta no deben estar obligadas a implementar partes que no utilizaran.

Para cumplir con este principio se requiere crear interfaces robustas que definan comportamientos específicos.

Una clase no debe estar obligada a implementar métodos que no usará o son innecesarios.

Las interfaces ayudan a desacoplar partes del sistema, Si se requiere se puede dividir una interfaz compleja en dos o más que contengan métodos que sabemos serán implementados en su totalidad por las clases que la hereden.

Este principio debe asegurar que las clases que hereden una interfaz hagan uso de todos los métodos implementados. No se debe forzar a la subclase a heredar métodos innecesarios.

DIP: Dependency Inversion Principle.

Principio Inyección de dependencias: Las clases de alto nivel no deberían depender de clase de bajo nivel, estas deberían depender de sus abstracciones.

El objetivo de este principio es conseguir desacoplar las clases, lograr que los módulos de la aplicación no dependan unos de otros, pero tampoco de componentes externos como bases de datos.

Para eliminar dependencias en el código hacemos uso de las interfaces y clases abstractas.

Si una clase necesita de otra, la inicialización de esta segunda clase debería venir desde fuera, es decir, no crear objetos dentro de una clase, por el contrario, los métodos de mi clase requieren recibir como parámetro los objetos ya inicializados.

La creación de objetos debe estar centralizada y no desperdigada por todo el código, esto nos permite controlar de forma óptima la creación de nuevos objetos.

Con este principio se logra extraer la responsabilidad de creación de objetos a un componente para delegárselo a otro, esto permite crear un mecanismo, para que el nuevo objeto, pueda ser cambiado por otro en tiempo de ejecución.

Últimas notas sobre los principios SOLID

Como hemos visto los principios SOLID son únicos y a la vez están encadenados. Es fundamental conocer y aplicar estos principios a cualquier desarrollo de software con el fin de hacer que se más robusto, escalable y mantenible

Esto solo es la introducción al estudio metódico de cada uno de los principios SOLID. En futuras entrega estaremos desmenuzando y comprendiendo de mejor forma cada uno de estos principios.

Te invitó a seguirme en mis redes sociales @OsvaldoGalvanR donde continuamente comparto información de interés y recursos útiles para programadores.

Facebook
Twitter
LinkedIn
Osvaldo Galván

Osvaldo Galván

Osvaldo Galván Software Engennier Enfocado en la calidad del software,
Temas:

Deja un comentario

Tu dirección de correo electrónico no será publicada.