Principio de inversión de dependencia: ¿Cómo definir la "política de alto nivel" y el "detalle de bajo nivel" para otras personas?

Estoy tratando de explicar el principio de inversión de dependencia a mis colegas (en su mayoría junior). ¿Cómo podemos definir cuál es la "política de alto nivel" y cuál es el "detalle de bajo nivel" en un software? Por ejemplo, si nuestro software automatiza el flujo de trabajo de varias aplicaciones comerciales, ¿por qué decimos que la automatización del flujo de trabajo es la política de alto nivel y las aplicaciones comerciales son los detalles?

Nota: esto ha sido completamente reescrito de mi ejemplo anterior

Piensa en tomas de corriente. En cualquier nación, la política de alto nivel es que los enchufes de energía son siempre los mismos. No importa de dónde obtenga la electricidad (carbón, gas, nuclear), los enchufes en la pared siempre deben emitir la misma cantidad de energía, a través del mismo conjunto de conectores.

Ahora puede enchufar cualquier dispositivo en ese zócalo, porque todos tienen una interfaz común, el "enchufe". La política de alto nivel nunca tiene que dictar ninguna parte de ese detalle de implementación. Simplemente conecte algo y listo.

Ahora, si tiene un dispositivo que no quiere alimentación de CA, tal vez se ejecuta en un circuito de CC de 7 V, aún puede usar esa política de alto nivel, solo necesita algún tipo de adaptador entre la fuente de alimentación y el dispositivo. Y, dado que todos tienen la misma política de alto nivel, el fabricante puede incorporarla a la implementación, sin ningún cambio en la política de alto nivel. La persona que conecta la implementación a la política (usted, conectando su computadora portátil) tampoco necesita entenderlo.

Además, si el fabricante quiere vender el mismo dispositivo en otro país, todo lo que tiene que hacer es desarrollar un adaptador diferente. Entonces, la misma implementación puede funcionar con múltiples políticas, mientras que la misma política puede ejecutar múltiples implementaciones.

Este es un ejemplo perfecto de inversión de dependencia.

Pero aquí está lo interesante: regrese a lo que dije por primera vez. "No importa de dónde obtengas la electricidad". Este también es un detalle de implementación. La política de alto nivel sigue siendo que todos los enchufes tienen la misma forma y emiten el mismo tipo de energía. Los detalles de implementación de bajo nivel son tanto de dónde proviene la electricidad como a qué se dirige.

En términos de programación, eso significa que la política de alto nivel es la interfaz (donde un lenguaje lo admite. Otra forma de DI es el tipeo de pato) que proporciona una API y la aplicación consume, y los detalles de implementación de bajo nivel son ambos la aplicación la consume y la API en sí, ninguna de las cuales necesita entenderse entre sí.

Los adaptadores pueden usarse para ajustar la misma implementación en diferentes políticas.

El enfoque clásico en la reutilización de software es construir componentes que no dependen de nada más (eso es lo que los hace de bajo nivel), y luego construir componentes de nivel superior que dependen de componentes de nivel inferior. "alto nivel" y "bajo nivel" están determinados específicamente por la dirección de la dependencia, que no es inherente a la función del componente, sino que a menudo es solo una decisión arquitectónica.

Por lo tanto, cuando las aplicaciones empresariales individuales se crean sin depender de la automatización del flujo de trabajo, pero su controlador de flujo de trabajo tiene dependencias directas de la aplicación empresarial, entonces debe quedar claro que la automatización del flujo de trabajo es una "política de alto nivel" y la aplicación empresarial es un componente de "bajo nivel". Tenga en cuenta que esta estructura no es obligatoria: si su componente de automatización de flujo de trabajo es un marco general, que tampoco está acoplado a sus aplicaciones comerciales específicas, pero puede configurarse para servir diferentes aplicaciones, entonces ya ha comenzado a aplicar el DIP. En esta situación, la separación de "alto nivel" / "bajo nivel" puede que ya no tenga sentido entre esas dos cosas.

Por lo tanto, el nombre "inversión de dependencia" es algo engañoso, ya que las dependencias no están "invertidas", sino que se eliminan por completo (o para ser más precisos: cambiaron de dependencias de tiempo de compilación a dependencias de tiempo de ejecución).

Yo uso una imagen simple para explicar DIP. La vista clásica del desarrollo de software es como un proceso de construcción con cada capa encima de las capas inferiores que lo soportan. Usar el principio de inversión de dependencia es más como construir un móvil.

En lugar de las capas superiores ubicadas en las capas inferiores, las capas superiores en la interfaz móvil con las capas inferiores a través de la cadena que las conecta. En cierto modo, las capas inferiores dependen de esa interfaz para soporte (sin la cadena que caerían). Eso es DIP en pocas palabras.