Unidad I Sesión 4 - Solid

UNIDAD I
INDICE
Los principios SOLID

¿Qué son la cohesión y el acoplamiento?
Acoplamiento
Cohesión
Principio de Responsabilidad Única
Principio de Abierto/Cerrado
Principio de Sustitución de Liskov
Principio de Segregación de la Interfaz
Principio de Inversión de Dependencias
Críticas a SOLID
Conclusión
SOLID (Introducción)
Si hablamos de diseño y desarrollo de aplicaciones, SOLID es una palabra que debes conocer
como uno de los fundamentos de la arquitectura y desarrollo de software.
SOLID es el acrónimo que acuñó Michael Feathers, basándose en los principios de la

programación orientada a objetos que Robert C. Martin (el tío Bob) había recopilado en el año
2000 en su paper “Design Principles and Design Patterns”.
Ocho años más tarde, el tío Bob siguió compendiando consejos y buenas prácticas de desarrollo
y se convirtió en el padre del código limpio con su célebre libro Clean Code.
¿Existen más principios de diseño? Claro que sí.
Sin embargo, estos son los más conocidos y aplicados en el diseño orientado a objetos.
SOLID (Objetivos)
Entre los objetivos de tener en cuenta estos 5 principios a la hora de escribir
código encontramos:
• Crear un software eficaz: que cumpla con su cometido y que sea robusto y

estable.
• Escribir un código limpio y flexible ante los cambios: que se pueda modificar
fácilmente según necesidad, que sea reutilizable y mantenible.
• Permitir escalabilidad: que acepte ser ampliado con nuevas funcionalidades
de manera ágil.
En definitiva, desarrollar un software de calidad.
En este sentido la aplicación de los principios SOLID está muy relacionada con la
comprensión y el uso de patrones de diseño, que nos permitirán mantener
una alta cohesión y, por tanto, un bajo acoplamiento de software.

¿Qué son la cohesión y el acoplamiento?
Son dos conceptos muy relevantes a la hora de diseñar y desarrollar software.
Acoplamiento
El acoplamiento se refiere al grado de interdependencia que tienen dos unidades de
software entre sí, entendiendo por unidades de software: clases, subtipos, métodos,
módulos, funciones, bibliotecas, etc.
Si dos unidades de software son completamente independientes la una de la otra,
decimos que están desacopladas.
Cohesión
La cohesión de software es el grado en que elementos diferentes de un sistema
permanecen unidos para alcanzar un mejor resultado que si trabajaran por separado.
Se refiere a la forma en que podemos agrupar diversas unidades de software para crear
una unidad mayor.
SOLID (Principios)
Los 5 principios SOLID de diseño de aplicaciones de software son:
• S – Single Responsibility Principle (SRP)
• O – Open/Closed Principle (OCP)
• L – Liskov Substitution Principle (LSP)
• I – Interface Segregation Principle (ISP)
• D – Dependency Inversion Principle (DIP)

Principio de Responsabilidad Única
“A class should have one, and only one, reason to change.”
La S del acrónimo se refiere a Single Responsibility Principle (SRP).
Según este principio “una clase debería tener una, y solo una, razón para
cambiar”. Es esto, precisamente, “razón para cambiar”, lo que Robert C. Martin
identifica como “responsabilidad”.
El principio de Responsabilidad Única es el más importante y fundamental de
SOLID, muy sencillo de explicar, pero el más difícil de seguir en la práctica.
El propio Bob resume cómo hacerlo:
• Reúne las cosas que cambian por las mismas razones.
• Separa aquellas que cambian por razones diferentes.

Ejemplo SRP
Esta clase podría cambiar por
varias razones:
1. El mecanismo para enviar podríamos utilizar distintos patrones de diseño para resolver el
problema. En este caso en particular, vamos a separar cada una de
correos es diferente. Por las formas de mandar mensajes en clases diferentes.
ejemplo, antes se usaba un
Así, cada clase tendría una única razón para cambiar.
servidor SMTP y ahora se
requiere usar un API. Por ejemplo, si en algún momento cambia la plataforma de
mensajes de texto, solo tenemos que modificar la clase EnvioSMS. Y
2. Cambios en la plataforma de si en algún momento pasamos de enviar correos con un servidor
La clase Mensajero, en la imagen,
mensajes de texto. SMTP a un API de un tercero, solo impactamos la clase EnvioCorreo.
tiene dos responsabilidades:
3. Aparición de una nueva forma
1. enviar correos y
de enviar mensajes.
2. enviar mensajes de texto.
Acabamos de ver 3 razones
diferentes por las cuales la clase
podría cambiar. Esto nos puede
traer problemas de mantenibilidad.
Principio de Abierto/Cerrado
“You should be able to extend a classes behavior, without modifying it.”
El segundo principio de SOLID lo formuló Bertrand Meyer en 1988 en su libro “

Object Oriented Software Construction” y dice: “Deberías ser capaz de extender el
comportamiento de una clase, sin modificarla”.
En otras palabras: las clases que usas deberían estar abiertas para poder
extenderse y cerradas para modificarse, o sea, si queremos añadir nuevo código,
lo ideal sería poder construir sobre lo que ya existe, sin tener que hacer
modificaciones grandes.
Es importante tener en cuenta el Open/Closed Principle (OCP) a la hora de
desarrollar clases, librerías o frameworks.
Ejemplo Open/Close
Supongamos que ahora queremos enviar
mensajes usando el chat corporativo de la
empresa.
Tal como quedó el refactor del ejemplo
anterior, serían necesarios los siguientes
cambios:
1. Crear una nueva clase llamada EnvioChat.

2. Agregar un nuevo método en la clase
Mensajero para enviar mensajes por chat.
3. Crear una instancia de EnvioChat en la
clase Mensajero.
Los cambios se verían así:
Esto no sería lo más óptimo. Cada vez que añadamos una nueva forma de
envío, sería necesario modificar la clase Mensajero. Además, habría que
cambiar todos los lugares donde se llamen los métodos de Mensajero para
que tengan en cuenta la nueva forma de enviar mensajes.
Este es un ejemplo donde no estamos respetando el principio de abierto
cerrado.
Ejemplo Open/Close
¿Cómo lo podemos mejorar?
Añadiendo mayor flexibilidad.
Flexibilidad que nos permita añadir nuevos

mecanismos de forma fácil, sin tener que
modificar lo que ya funciona.
Allí, de nuevo, vienen los patrones al

rescate:
• Lo primero que podríamos hacer es crear

una interfaz que nos permita definir el
comportamiento de cualquier clase que
sea capaz de enviar un mensaje.
• Luego, ponemos a cada una de las clases
especializadas en envíos a que la
implementen.
(Notarás una nueva clase, Mensaje, que sirve para unificar los parámetros que recibe
el método enviar).
Si estás familiarizado con el patrón adaptador, algo muy similar es lo que
verás en ese diagrama. Cada clase está especializada en conectarse con una
forma diferente de enviar mensajes.
Ejemplo Open/Close
La solución final
Lo que necesitamos ahora es

quitarle el conocimiento a la clase
Mensajero de las distintas clases
que envían mensajes.
Para esto, podemos implementar

una fábrica.
Teniendo la fábrica, la clase Mensajero ya no necesita métodos específicos por cada

método de envío. Solo necesita pedirle a la fábrica un objeto de tipo EnvioMensaje, e
invocar sobre este el método enviar.
Principio de Sustitución de Liskov
“Derived classes must be substitutable for their base classes.”
La L de SOLID alude al apellido de quien lo creó, Barbara Liskov.

Este principio nos habla específicamente de la herencia.
En pocas palabras, dice que siempre deberíamos poder reemplazar instancias de una
clase padre por instancias de una clase hija, sin que hayan comportamiento no
deseados.
Visto de otra manera, las clases hijas no deberían modificar o eliminar los
comportamientos definidos en el padre.
A diferencia de los principios anteriores, no hay algún patrón de diseño específico por
aplicar aquí. Sin embargo, tener a la mano patrones de diseño relacionados con la
herencia pueden ser muy útiles. Algunos ejemplos:
• Método plantilla.
• Estrategia.
• Composite
• Estado.
Según Robert C. Martin incumplir el Liskov Substitution Principle (LSP) implica violar
también el principio de Abierto/Cerrado.
Principio de Segregación de la Interfaz
“Make fine grained interfaces that are client specific.”
En el cuarto principio de SOLID, el tío Bob sugiere: “Haz interfaces que sean específicas
para un tipo de cliente”, es decir, para una finalidad concreta.
En este sentido, según el Interface Segregation Principle (ISP), es preferible contar con
muchas interfaces que definan pocos métodos que tener una interface forzada a
implementar muchos métodos a los que no dará uso.
Debemos tener cuidado con definir interfaces con muchos métodos. De acuerdo a este
principio, es mejor tener interfaces pequeñas, con pocos métodos muy relacionados
(alta cohesión), en lugar de tener interfaces voluminosas que obligan a definir
muchos métodos a quien las implementa.
Aquí el principio de única responsabilidad resulta muy útil, para separar esas interfaces
de la mejor manera.
Algunos patrones, especialmente los de comportamiento, pueden ser muy convenientes:
• Estrategia.
• Estado.
• Cadena de responsabilidad.
Principio de Inversión de Dependencias
“Depend on abstractions, not on concretions.”
Llegamos al último principio: “Depende de abstracciones, no de clases concretas”.

Así, Robert C. Martin recomienda:
1. Los módulos de alto nivel no deberían depender de módulos de bajo nivel.
Ambos deberían depender de abstracciones.
2. Las abstracciones no deberían depender de los detalles. Los detalles
deberían depender de las abstracciones.
El objetivo del Dependency Inversion Principle (DIP) consiste en reducir las
dependencias entre los módulos del código, es decir, alcanzar un bajo
acoplamiento de las clases.
En general todos los patrones que ayuden a abstraer nuestros módulos son
útiles para lograr este principio. En particular, es relevante mencionar:
• Fachada.
• Fábrica abstracta y método fábrica.
• Adaptador.
Críticas a SOLID
• El ámbito del desarrollo de software es un terreno de continuo debate y SOLID no se
queda fuera de la controversia.
• Aunque estos cinco principios son considerados por muchos como una base
fundamental de un buen desarrollo o al menos como una guía a tener en cuenta, no
son pocos los profesionales que critican los principios SOLID.
• Los acusan de ambiguos, confusos, de complicar el código, de demorar el proceso
de desarrollo y los tildan incluso de totalmente equivocados e innecesarios.
Conclusión
• Los principios SOLID son eso: principios, es decir, buenas prácticas que
pueden ayudar a escribir un mejor código: más limpio, mantenible y escalable.
• Como indica el propio Robert C. Martin no se trata de reglas, ni leyes, ni
verdades absolutas, sino más bien soluciones de sentido común a problemas
comunes. Son heurísticos, basados en la experiencia: “se ha observado que
funcionan en muchos casos; pero no hay pruebas de que siempre funcionen,
ni de que siempre se deban seguir.”
• Dice el tío Bob, que SOLID nos ayuda a categorizar lo que es un buen o mal
código y es innegable que un código limpio tenderá más a salir airoso del
“control de calidad de código”.
Calidad del código (WTF’s x minuto)

Unidad I Sesión 4 - Solid

Cargado por

Copyright:

Formatos disponibles

Unidad I Sesión 4 - Solid

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Unidad I Sesión 4 - Solid

Cargado por

Copyright:

Formatos disponibles

UNIDAD I

Los principios SOLID

SOLID es el acrónimo que acuñó Michael Feathers, basándose en los principios de la

¿Existen más principios de diseño? Claro que sí.

• Crear un software eficaz: que cumpla con su cometido y que sea robusto y

En definitiva, desarrollar un software de calidad.

Son dos conceptos muy relevantes a la hora de diseñar y desarrollar software.

• S – Single Responsibility Principle (SRP)

• O – Open/Closed Principle (OCP)

• L – Liskov Substitution Principle (LSP)

• I – Interface Segregation Principle (ISP)

• D – Dependency Inversion Principle (DIP)

La S del acrónimo se refiere a Single Responsibility Principle (SRP).

El segundo principio de SOLID lo formuló Bertrand Meyer en 1988 en su libro “

1. Crear una nueva clase llamada EnvioChat.

Los cambios se verían así:

Añadiendo mayor flexibilidad.

Flexibilidad que nos permita añadir nuevos

Allí, de nuevo, vienen los patrones al

• Lo primero que podríamos hacer es crear

Lo que necesitamos ahora es

Para esto, podemos implementar

Teniendo la fábrica, la clase Mensajero ya no necesita métodos específicos por cada

La L de SOLID alude al apellido de quien lo creó, Barbara Liskov.

Llegamos al último principio: “Depende de abstracciones, no de clases concretas”.

También podría gustarte