Principios SOLID

Técnicas de Programación y Laboratorio

León Jaramillo
Principios SOLID
GRASP y SOLID

Principios SOLID 2
Síntomas de un Diseño Pobre
• Rigidez: El diseño es difícil de cambiar, porque cada cambio fuerza muchos
otros cambios en otras partes del sistema.
• Fragilidad: Un cambio en el diseño causa que el sistema se “quiebre” en
lugares sin relación conceptual con la parte cambiada.
• Inmovilidad: Es difícil descomponer el sistema en componentes que
puedan ser reutilizados en otros sistemas.
• Viscosidad: Es difícil de hacer las cosas bien en cuanto al diseño. Se fuerza
a realizar cambios en el código en contra del diseño ya planteado.
• Complejidad innecesaria o sobre-diseño.
• Repetición innecesaria: Exceso de copy/paste.
• Opacidad: Diseño desordenado y difícil de entender. Que no es capaz de
expresar bien su propósito y funcionamiento.

Principios SOLID 3
Principios SOLID
Principios de diseño que buscan atacar los anteriores síntomas.

Recopilados por Robert C. Martin en el libro Agile software development:

principles, patterns, and practices en 2003.

SOLID consta de los siguientes principios:

• SRP – The Single Responsibility Principle
• OCP – The Open/Closed Principle
• LSP – The Liskov Substitution Principle
• DIP – The Dependency Inversion Principle
• ISP – The Interface Segregation Principle
Principios SOLID 4
Principios SOLID y los Patrones de Diseño (y
Arquitecturales)
SOLID:
• Incluye la generalización de algunos patrones de diseño.
• Sienta las bases para la definición de otros patrones.
• Justifican la definición de algunos otros.

Robert C. Martin los ha acercado a los patrones arquitecturales en su

libro Clean architecture: a craftsman's guide to software structure and
design.

Principios SOLID 5
SRP – The Single Responsibility Principle
• Principio descrito en el trabajo de Tom DeMarco y Meilir Page-Jones,
y lo llamaron Cohesión.

• El principio reza:
“A class should have one, and only one, reason to change”
“Una clase debe tener una, y solo una, razón para cambiar”

• Pero también se puede parafrasear así:

“Un módulo debe ser responsable ante uno, y solo un, usuario o stakeholder”
“Un módulo debe ser responsable ante uno, y solo un, actor”

Principios SOLID 6
SRP – The Single Responsibility Principle
Ejemplo 1 (antes)

Principios SOLID 7
SRP – The Single Responsibility Principle
Ejemplo 1 (después)

Principios SOLID 8
SRP – The Single Responsibility Principle
Ejemplo 2 (antes)

Principios SOLID 9
SRP – The Single Responsibility Principle
Ejemplo 2 (después)

Principios SOLID 10
Responsabilidades que pueden necesitar
estar separadas
Persistencia

Validación

Notificaciones

Manejo de errores

Logging

Instanciación de clases

Formateo

Parsing

Principios SOLID 11
OCP – The Open/Closed Principle
• Este principio fue acuñado por Bertrand Meyer en 1988.

• Y reza así:
“Software entities (clases, modules, functions, etc.) should be open for
extensión, but closed for modification”
“Las entidades de software (clases, módulos, funciones, etc.) deben estar
abiertas a su extensión, pero cerradas a su modificación”

• Pero también se puede parafrasear así:

“Debe ser posible extender el comportamiento de un sistema sin tener que
modificarlo”

Principios SOLID 12
OCP – The Open/Closed Principle
Lo anterior quiere decir:

• Abierto a su extensión:
El comportamiento de la clase o módulo se puede modificar, agregando nuevos
comportamientos a la clase o módulo.

• Cerrado a su modificación:
La modificación de dicho comportamiento, solo se hace mediante extensión,
evitando la modificación del código fuente de la clase o módulo.

Principios SOLID 13
OCP – The Open/Closed Principle
Ejemplo 1 (antes)

Principios SOLID 14
OCP – The Open/Closed Principle
Ejemplo 1 (después)

Principios SOLID 15
LSP – The Liskov Substitution Principle
• El principio fue acuñado por Barbara Liskov en 1988 así:
“What is wanted here is something like the following substitution property: If
for each object o1 of type S there is an object o2 of type T such that for all
programs P defined in terms of T, the behavior of P is unchanged when o1 is
substituted for o2 then S is a subtype of T”

• Pero puede ser parafraseado así:

“Los subtipos deben poder sustituirse con sus tipos base”
“Una subclase debe poder sustituirse con su superclase”

Principios SOLID 16
LSP – The Liskov Substitution Principle
¿Qué pasa aquí?

Rectangle r = …
r.setW(5);
r.setH(2);
assert(r.area() == 10);

Principios SOLID 17
LSP – The Liskov Substitution Principle
Síntomas de la violación de dicho principio

Lanzamiento de excepciones
Funciones “degeneradas” en
en las subclases (que no se
las subclases o subtipos
lanzaban en las superclases)

Principios SOLID 18
DIP – The Dependency Inversion Principle
• El principio reza:
a. “High level modules should not depend on low level modules. Both should
depend on abstractions.”
b. “Abstractions should not depend on details. Details should depend on
abstractions.”

• Los diseños más flexibles son aquellos en los cuales las dependencias
en el código fuente se refieren más abstracciones que a concreciones.

• Este principio se fundamenta en la dicotomía entre abstracto y

concreto, y en las capas del diseño del sistema.
Principios SOLID 19
DIP – The Dependency Inversion Principle
Capas del Diseño del Sistema

Principios SOLID 20
DIP – The Dependency Inversion Principle
Una Heurística
• No referirse a o depender de clases concretas volátiles
• Existen clases no volátiles de las que no tiene sentido desligarse (como String
en Java)

• No heredar de (o extender) clases concretas volátiles

• No sobreescribir funciones concretas

• No mencionar el nombre de nada concreto ni volátil

• ¿Ejemplos de elementos volátiles?

Principios SOLID 21
DIP – The Dependency Inversion Principle
Ejemplo 1 (antes)

Principios SOLID 22
DIP – The Dependency Inversion Principle
Ejemplo 1 (después)

Principios SOLID 23
ISP – The Interface Segregation Principle
• Este principio reza así:
“Clients should not be forced to depend on methods that they do not use.”

• Se fundamenta en evitar interfaces saturadas o poco cohesivas,

reemplazándolas por interfaces más livianas y con mayor cohesión
entre sus operaciones.

• De existir una clase con una interfaz concreta poco cohesiva, una
clase cliente puede hacer uso de varias interfaces de una mayor
cohesión, de acuerdo con sus necesidades.

Principios SOLID 24
ISP – The Interface Segregation Principle
Ejemplo 1 (antes)

Principios SOLID 25
ISP – The Interface Segregation Principle
Ejemplo 1 (después)

Principios SOLID 26
ISP – The Interface Segregation Principle
Ejemplo 2 (antes)

Principios SOLID 27
ISP – The Interface Segregation Principle
Ejemplo 2 (después)

Principios SOLID 28
ISP – The Interface Segregation Principle
Ejemplo 3 (antes)

Principios SOLID 29
ISP – The Interface Segregation Principle
Ejemplo 3 (antes)

Principios SOLID 30
ISP – The Interface Segregation Principle
Ejemplo 3 (después)

Principios SOLID 31
Recordando… Principios SOLID

SRP – The Single Responsibility Principle

OCP – The Open/Closed Principle

LSP – The Liskov Substitution Principle

DIP – The Dependency Inversion Principle

ISP – The Interface Segregation Principle

Principios SOLID 32
Bibliografía
Martin, R. C. (2003). Agile software development: principles, patterns,
and practices. Prentice Hall.
Martin, R. C. (2017). Clean architecture: a craftsman's guide to
software structure and design. Prentice Hall Press.

Principios SOLID 33