Principios SOLID

Principios SOLID
Luis Aimacaña
Danny Colimba
Doménica Erazo
Marvin Salcedo
Introducción
Michael
Feathers SOLID: acrónimo acuñado por Michael Feathers,
basándose en los principios de la programación
orientada a objetos.
En el año 2000, Robert C. Martin, recopila toda

información sobre el estudio de Michael, lo que le
permitió publicar los principios en su libro Agile
Software Development: Principles, Patterns, and
Robert C. Practices.
Martin
Conjunto de principios aplicados al POO
que ayudan a desarrollar software de
¿Qué son los calidad en cualquier lenguaje de
programación orientada a objetos. Su
principios SOLID? intención es eliminar los malos diseños,

evitar la refactorización, construir código
más eficiente, fácil de testear y mantener.
“Principios que facilita a los Código con:
desarrolladores la labor de crear ❖ Bajo Acoplamiento
programas legibles y mantenibles.” ❖ Alta Cohesión
S – Single
Responsibility
Principle (SRP)
Los D – Dependency
Inversion
Principle (DIP)
O–
Open/Closed
Principle (OCP)
principios
SOLID
I – Interface L – Liskov
Segregation Substitution
Principle (ISP) Principle (LSP)
S
Es el Single Responsibility Principle, también
conocido por sus propias siglas en inglés SRP.
Principio de Este principio establece que cada clase debe tener

una única responsabilidad dentro de nuestro
software.
Responsabilidad ➔ Definida
Única ➔ Concreta
Definir la responsabilidad única de una clase no es
una tarea fácil, será necesario un análisis previo de
las funcionalidades y cómo estructuramos la
aplicación.
Tips para saber si no estamos cumpliendo con este principio
❖ En una misma clase están involucradas dos capas de la arquitectura

❖ Nos cuesta testear la clase
❖ Por el número de líneas
O
El principio de abierto-cerrado (OCP, por sus
siglas en inglés).
Este principio establece que una entidad de
Principio software (clase, módulo, función, etc) debe quedar

abierta para su extensión, pero cerrada para su
modificación.
abierto / cerrado ➔ Abierto a extensión: quiere decir
tienes que ser capaz de añadir nuevas
funcionalidades.
➔ Cerrado a modificación: quiere decir

que para añadir la nueva funcionalidad no
tienes que cambiar código que ya está
escrito.
Beneficios
Las ventajas que nos ofrece diseñar el código aplicando este principio
❖ Es un software más fácil de mantener al minimizar los cambios en la base de

código de la aplicación y de ampliar funcionalidades sin modificar partes
básicas de la aplicación probadas.
❖ También vemos las ventajas a la hora de implementar test unitarios en nuestro
software
Ejemplo
L Principio de Sustitución de
Liskov
Definición matemática
Si para cada objeto o1 de tipo S hay un objeto o2 de tipo T tal que para todos los
programas P definidos en términos de T, el comportamiento de P no cambia cuando o1
es sustituido por o2, entonces S es un subtipo de T.
En otras palabras, el principio nos dice que si en alguna parte de

nuestro código estamos usando una clase y esta es extendida,
tenemos que poder utilizar cualquier clase hija y el programa
debe seguir funcionando
¿Cómo saber si estamos
fallando este principio?
➔ La principal manera de darnos cuenta de que
esto ha sucedido es que creamos una clase
que extiende a otra y de repente nos sobra un
método
➔ Si un método sobreescrito no hace nada o

lanza una excepción.
Es así que el principio de Liskov nos ayuda a
utilizar las herencias de manera correcta y saber
como extender las clases. Se debe comprender
que no hay una modelización de todos los
aspectos de la vida real, así que este principio nos
ayudará a hacerlo.
I Segregación de
Interfaces
“Ninguna clase debería depender de
métodos que no usa”
“Las interfaces nos ayudan a

desacoplar módulos entre sí”
“La problemática surge cuando las

interfaces intentar definir más cosas
de las debidas” Fat Interfaces
¿Cómo detectar Si tenemos una interfaz que tiene algunos
métodos cuyas clases hijas no están
implementando porque no lo necesitan. entonces
que estamos estamos violando el principio de segregación

Si la interfaz forma parte del código y se la
pueda modificar, entonces lo ideal es dividir la
fallando este
interfaz en varias pequeñas para que cuando las
clases la implementen no queden funciones
vacías
principo?
El Principio de Segregación de Interfaces ayuda a poder crear nuestra arquitectura utilizando la
composición de protocolos o interfaces, evitando así los Fat Interfaces que en la mayoría de los
casos obligan a dejar métodos vacíos o lanzar errores en aquellos métodos que no tiene sentido
implementar.
D Inversión de
Dependencias
““Depende de abstracciones, no de clases concretas”.”
Las clases de alto nivel no deberían

depender de las clases de bajo nivel.
Ambas deberían depender de las
abstracciones.
Las abstracciones no deberían depender

de los detalles. Los detalles deberían
depender de las abstracciones.
El problema
En la programación vista desde el modo tradicional, cuando un módulo depende de otro
módulo, se crea una nueva instancia y la utiliza sin más complicaciones
● Las parte más genérica de nuestro

código (lo que llamaríamos el dominio o
lógica de negocio) dependerá por todas
partes de detalles de implementación.
● No quedan claras las dependencias
● Es muy complicado hacer tests
Ejemplo
Boton depende de
Lámpara
Si Lampara cambia, Boton
cambiará también.
● La política de alto nivel de la aplicación no ha sido

separada de la implementación de bajo nivel.
● Las abstracciones no han sido separadas de los Boton no es reusable
detalles
● La política de alto nivel automáticamente depende
de los módulos de bajo nivel, las abstracciones No podrías usar presionar() para
automáticamente dependen en los detalles. encender una Lavadora, por
ejemplo.
Solución
Creemos una capa intermedia en
donde definiremos una interfaz
abstracta asociada a Boton e
implementada por cualquier clase
como Lampara.
De este modo:
● Boton depende únicamente de abstracciones, puede ser reusado en varias clases que
implementen Conmutable. Por ejemplo, Lavadora o Ventilador
● Cambios en Lampara no afectarán a Boton.
● ¡Las dependencias han sido invertidas! ahora Lampara tiene que adaptarse a la
interfaz definida por Boton. Lo cual tiene sentido, ya que la idea fundamental es que
lo más importante no dependa de lo menos importante.
Conclusiones
● Aplicar los principios de SOLID nos permitirá crear
software más ordenado, limpio y fácil de mantener
● En sistemas cuyo tamaño se considera grande, y
donde existen muchos módulos, librerías y
funciones, contar con estos principios no solo
ayudará en el mantenimiento, también a crecer el
código de manera más eficiente y limpia.
● Los principios SOLID son buenas prácticas, no son
leyes ni reglas.
● Funcionan en muchos casos, pero no hay pruebas
de que siempre funcionen ni de que siempre se
deban seguir.
Referencias
(2022). Retrieved 19 January 2022, from https://repositorio.grial.eu/bitstream/grial/355/1/Liskov.pdf
Principio de sustitución de Liskov (SOLID 3ª parte). (2016). Retrieved 19 January 2022, from
https://devexperto.com/principio-de-sustitucion-de-liskov/
Principio de segregación de interfaces (SOLID 4ª parte). (2016). Retrieved 19 January 2022, from
https://devexperto.com/principio-de-segregacion-de-interfaces/
[S.O.L.I.D.] Open-Closed Principle / Principio Abierto-Cerrado - Adictos al trabajo. (2014). Retrieved 20 January
2022, from https://www.adictosaltrabajo.com/2014/10/23/solid-2/
▷ Guía definitiva de Principios SOLID - Explicados con Laravel. (2019). Retrieved 20 January 2022, from
https://www.laraveltip.com/guia-definitiva-de-principios-solid-explicados-con-laravel/#Conclusion
SOLID: los 5 principios que te ayudarán a desarrollar software de calidad. (2022). Retrieved 20 January 2022,
from https://profile.es/blog/principios-solid-desarrollo-software-calidad/
Machillanda, J. (2020). SOLID: Principio de Inversión de Dependencias. Retrieved 20 January 2022, from
https://somospnt.com/blog/147-solid-principio-de-inversion-de-dependencias

Principios SOLID

Cargado por

Copyright:

Formatos disponibles

Principios 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

Principios SOLID

Cargado por

Copyright:

Formatos disponibles

Principios SOLID

En el año 2000, Robert C. Martin, recopila toda

principios SOLID? intención es eliminar los malos diseños,

Principio de Este principio establece que cada clase debe tener

❖ En una misma clase están involucradas dos capas de la arquitectura

Este principio establece que una entidad de

Principio software (clase, módulo, función, etc) debe quedar

➔ Cerrado a modificación: quiere decir

❖ Es un software más fácil de mantener al minimizar los cambios en la base de

En otras palabras, el principio nos dice que si en alguna parte de

➔ Si un método sobreescrito no hace nada o

“Las interfaces nos ayudan a

“La problemática surge cuando las

que estamos estamos violando el principio de segregación

Las clases de alto nivel no deberían

Las abstracciones no deberían depender

● Las parte más genérica de nuestro

● La política de alto nivel de la aplicación no ha sido

También podría gustarte