Princípio da inversão de dependência: como definir “política de alto nível” e “detalhes de baixo nível” para outras pessoas?

Estou tentando explicar o princípio da inversão de dependência para meus colegas (principalmente juniores). Como podemos definir qual é a "política de alto nível" e qual é o "detalhe de baixo nível" em um software? Por exemplo, se nosso software automatiza o fluxo de trabalho de vários aplicativos de negócios, por que dizemos que a automação do fluxo de trabalho é a política de alto nível e os aplicativos de negócios são os detalhes?

Nota: isso foi completamente reescrito no meu exemplo anterior

Pense em tomadas de energia. Em qualquer nação, a política de alto nível é que os soquetes de energia sejam sempre os mesmos. Não importa de onde você obtenha eletricidade (carvão, gás, energia nuclear), as tomadas na parede devem sempre fornecer a mesma quantidade de energia, através do mesmo conjunto de conectores.

Agora você pode conectar qualquer dispositivo a esse soquete, porque todos eles têm uma interface comum, o "plug". A política de alto nível nunca precisa ditar nenhuma parte desses detalhes de implementação. Basta conectar algo e pronto.

Agora, se você tiver um dispositivo que não deseja energia CA - talvez seja executado em um circuito de 7V CC - ainda poderá usar essa política de alto nível, apenas precisará de algum tipo de adaptador entre a fonte de alimentação e o dispositivo. E, como todos têm a mesma política de alto nível, o fabricante pode incorporá-lo à implementação, sem nenhuma alteração na política de alto nível. A pessoa que está conectando a implementação à política (você conectando o laptop) também não precisa entender.

Além disso, se o fabricante quiser vender o mesmo dispositivo em outro país, tudo o que eles precisam fazer é desenvolver um adaptador diferente. Portanto, a mesma implementação pode funcionar com várias políticas, enquanto a mesma política pode executar várias implementações.

Este é um exemplo perfeito de inversão de dependência.

Mas aqui está a parte interessante: Volte ao que eu disse pela primeira vez. "Não importa de onde você tira eletricidade." Este também é um detalhe de implementação. A política de alto nível ainda é a de que todos os soquetes de energia têm a mesma forma e emitem o mesmo tipo de energia. Os detalhes de implementação de baixo nível são de onde vem a eletricidade e o que é executado.

Em termos de programação, isso significa que a política de alto nível é a interface (onde uma linguagem a suporta. Outra forma de DI é a digitação de pato.) Que uma API fornece e o aplicativo consome, e os detalhes de implementação de baixo nível são os seguintes: aplicativo consumindo-o e a própria API, nenhum dos quais precisa se entender.

Os adaptadores podem ser usados ​​para ajustar a mesma implementação em políticas diferentes.

A abordagem clássica na reutilização de software é construir componentes que não dependem de mais nada (é isso que os torna de baixo nível) e, em seguida, construir componentes de nível superior que dependem de componentes de nível inferior. "alto nível" e "baixo nível" são determinados especificamente pela direção da dependência, que não é inerente à função do componente, mas geralmente apenas uma decisão arquitetural.

Portanto, quando aplicativos de negócios únicos são construídos sem dependência da automação do fluxo de trabalho, mas seu controlador de fluxo de trabalho tem dependências diretas do aplicativo de negócios, deve ficar claro que a automação do fluxo de trabalho é uma "política de alto nível" e o aplicativo de negócios é um componente "baixo nível". Observe que essa estrutura não é obrigatória - se o componente de automação do fluxo de trabalho for uma estrutura geral, que também não é acoplada aos aplicativos de negócios específicos, mas pode ser configurada para atender a aplicativos diferentes, você já começou a aplicar o DIP. Nessa situação, a separação "alto nível" / "baixo nível" pode não fazer mais sentido entre essas duas coisas.

Portanto, o nome "inversão de dependência" é um pouco enganador - já que as dependências não são "inversas", mas completamente removidas (ou, para ser mais preciso: mudou de ser dependências de tempo de compilação para dependências de tempo de execução).

Eu uso uma imagem simples para explicar o DIP. A visão clássica do desenvolvimento de software é como um processo de construção, com cada camada sobre as camadas inferiores que a suportam. Usar o Princípio da inversão de dependência é mais como construir um celular.

Em vez de as camadas mais altas ficarem nas camadas inferiores, as camadas mais altas na interface móvel com as camadas inferiores por meio da cadeia que as conecta. De certa forma, as camadas inferiores dependem dessa interface para suporte (sem a string que elas cairiam). Isso é DIP em poucas palavras.