Scribd
Cargar
150 vistas4 páginas

Solid

El documento describe los cinco principios de SOLID, una guía para el diseño de software orientado a objetos. SOLID es un acrónimo que representa los principios de responsabilidad única (S), abierto/cerrado (O), sustitución de Liskov (L), segregación de interfaz (I) y inversión de dependencias (D). Cada principio promueve diseños de software flexibles, reutilizables y fáciles de mantener.

Cargado por

Hilbert Perucho
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
150 vistas4 páginas

Solid

El documento describe los cinco principios de SOLID, una guía para el diseño de software orientado a objetos. SOLID es un acrónimo que representa los principios de responsabilidad única (S), abierto/cerrado (O), sustitución de Liskov (L), segregación de interfaz (I) y inversión de dependencias (D). Cada principio promueve diseños de software flexibles, reutilizables y fáciles de mantener.

Cargado por

Hilbert Perucho
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
Está en la página 1/ 4

Principios de Solid

SOLID es un acrónimo acuñado por Robert C.Martin para definir los cinco principios básicos de la
programación orientada a objetos

Estos principios se llamaron S.O.L.I.D. por sus siglas en inglés:

 S: Single responsibility principle o Principio de responsabilidad única


 O: Open/closed principle o Principio de abierto/cerrado
 L: Liskov substitution principle o Principio de sustitución de Liskov
 I: Interface segregation principle o Principio de segregación de la interfaz
 D: Dependency inversion principle o Principio de inversión de dependencia

S: Principio de responsabilidad única


Como su propio nombre indica, establece que una clase, componente o microservicio debe ser
responsable de una sola cosa (el tan aclamado término “decoupled” en inglés). Si por el contrario,
una clase tiene varias responsabilidades, esto implica que el cambio en una responsabilidad
provocará la modificación en otra responsabilidad.

Ejemplo:

O: Principio abierto/cerrado
Establece que las entidades software (clases, módulos y funciones) deberían estar abiertos para su
extensión, pero cerrados para su modificación.

L: Principio de substitución de Liskov


Declara que una subclase debe ser sustituible por su superclase, y si al hacer esto, el programa falla,
estaremos violando este principio.

Cumpliendo con este principio se confirmará que nuestro programa tiene una jerarquía de clases
fácil de entender y un código reutilizable.

Ejemplo:

I: Principio de segregación de interfaz


Este principio establece que los clientes no deberían verse forzados a depender de interfaces que
no usan.

Dicho de otra manera, cuando un cliente depende de una clase que implementa una interfaz cuya
funcionalidad este cliente no usa, pero que otros clientes sí usan, este cliente estará siendo afectado
por los cambios que fuercen otros clientes en dicha interfaz.
D: Principio de inversión de dependencias
Establece que las dependencias deben estar en las abstracciones, no en las concreciones. Es decir:

Los módulos de alto nivel no deberían depender de módulos de bajo nivel. Ambos deberían
depender de abstracciones.

Las abstracciones no deberían depender de detalles. Los detalles deberían depender de


abstracciones.

En algún momento nuestro programa o aplicación llegará a estar formado por muchos módulos.
Cuando esto pase, es cuando debemos usar inyección de dependencias, lo que nos permitirá
controlar las funcionalidades desde un sitio concreto en vez de tenerlas esparcidas por todo el
programa. Además, este aislamiento nos permitirá realizar testing mucho más fácilmente.

También podría gustarte