0% encontró este documento útil (0 votos)
8 vistas1 página

Principio de Inversión de Dependencias

El Principio de Inversión de Dependencias (DIP) establece que los módulos de alto y bajo nivel deben depender de abstracciones para lograr un código más flexible y fácil de mantener. Un ejemplo positivo muestra cómo un servicio de notificaciones puede depender de una interfaz, permitiendo la extensión sin modificar el código existente. En contraste, un ejemplo negativo ilustra cómo depender directamente de una implementación específica hace que el código sea rígido y difícil de mantener.
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 DOCX, PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
8 vistas1 página

Principio de Inversión de Dependencias

El Principio de Inversión de Dependencias (DIP) establece que los módulos de alto y bajo nivel deben depender de abstracciones para lograr un código más flexible y fácil de mantener. Un ejemplo positivo muestra cómo un servicio de notificaciones puede depender de una interfaz, permitiendo la extensión sin modificar el código existente. En contraste, un ejemplo negativo ilustra cómo depender directamente de una implementación específica hace que el código sea rígido y difícil de mantener.
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 DOCX, PDF, TXT o lee en línea desde Scribd

DAYANA SALETH ORTUÑO GUZMÁN

DEPENDENCY INVERSION PRINCIPLE


DEFENICIÓN:

El Principio de Inversión de Dependencias (DIP) establece que los


módulos de alto nivel y bajo nivel deben depender de abstracciones,
no de implementaciones concretas. Esto permite un código más
flexible, desacoplado y fácil de mantener, facilitando la evolución del
software y la reutilización sin afectar otras partes del sistema.
EJEMPLO:

✔ ServicioNotificaciones depende
de la interfaz Notificador, no de una
implementación específica.
✔ Fácil de extender: podemos agregar
nuevos notificadores sin cambiar
ServicioNotificaciones.
✔ Código flexible y reutilizable:
podemos cambiar la implementación de
notificación sin modificar la clase
principal.

CONTRAEJEMPLO:

❌ Por qué viola el DIP

❌ ServicioNotificaciones depende
directamente de EmailNotificador, lo
que lo hace rígido.
❌ Si queremos agregar SMS u otro
método, tenemos que modificar
ServicioNotificaciones, rompiendo
OCP (Open/Closed Principle).
❌ Difícil de mantener y probar porque no
podemos cambiar el método de notificación
sin tocar la clase principal.

También podría gustarte