Meus 2 centavos ...
Sim e não.
Você nunca deve realmente violar os princípios que você adota; mas, seus princípios devem sempre ser matizados e adotados a serviço de um objetivo maior. Assim, com um entendimento adequadamente condicionado, algumas aparentes violações podem não ser reais violações do "espírito" ou "corpo de princípios como um todo".
Os princípios do SOLID em particular, além de exigir muitas nuances, são, em última análise, subservientes ao objetivo de "entregar software de trabalho e de manutenção". Portanto, aderir a qualquer princípio específico do SOLID é autodestrutivo e contraditório quando isso entra em conflito com os objetivos do SOLID. E aqui, muitas vezes observo que
entrega supera
manutenção .
Então, o que acontece com o D em SOLID ? Bem, isso contribui para uma maior manutenibilidade ao tornar seu módulo reutilizável relativamente agnóstico à sua contexto. E podemos definir o "módulo reutilizável" como "uma coleção de código que você planeja usar em outro contexto distinto". E isso se aplica a uma única função, classe, conjunto de classes e programas.
E sim, alterar as implementações do criador de logs provavelmente coloca seu módulo em um "outro contexto distinto".
Então, deixe-me oferecer minhas duas grandes advertências :
Primeiramente: Desenhar as linhas em torno dos blocos de código que constituem "um módulo reutilizável" é uma questão de julgamento profissional. E seu julgamento é necessariamente limitado à sua experiência .
Se você não atualmente planeja usar um módulo em outro contexto, provavelmente está OK para que ele dependa disso indefesamente. A ressalva para a advertência: Seus planos provavelmente estão errados - mas isso é também OK. Quanto mais tempo você escrever módulo após módulo, mais e mais intuitivo e preciso será o sentido de "eu preciso disso novamente algum dia". Mas, provavelmente, você nunca poderá dizer retrospectivamente: "Eu modulei e desvinculei tudo o máximo possível, mas sem excesso."
Se você se sentir culpado por seus erros de julgamento, confesse-se e siga em frente ...
Em segundo lugar: Inverter o controle não é igual a injetando dependências .
Isso é especialmente verdadeiro quando você inicia injetando dependências ad nauseam . A Injeção de Dependência é uma tática útil para a estratégia global da IoC. Mas, eu diria que a ID é de menor eficácia do que algumas outras táticas - como usar interfaces e adaptadores - único pontos de exposição ao contexto a partir do módulo .
E vamos nos concentrar nisso por um segundo. Porque, mesmo que você injete um Logger
ad nauseam , você precisa escrever código na interface Logger
. Você não pode começar a usar um novo Logger
de um fornecedor diferente que recebe parâmetros em uma ordem diferente. Essa habilidade vem da codificação, dentro do módulo, contra uma interface que existe dentro do módulo e que possui um único sub-módulo (Adapter) para gerenciar a dependência.
E se você estiver codificando em um Adaptador, se o Logger
é injetado nesse Adaptador ou descoberto pelo Adaptador é geralmente muito insignificante para o objetivo geral de manutenção. E o mais importante, se você tiver um adaptador de nível de módulo, provavelmente é apenas absurdo injetá-lo em qualquer coisa. Está escrito para o módulo.
tl; dr - Pare de se preocupar com princípios sem considerar por que você está usando os princípios. E, de forma mais prática, basta criar um Adapter
para cada módulo. Use o seu julgamento ao decidir onde você desenha os limites do "módulo". De dentro de cada módulo, vá em frente e consulte diretamente o Adapter
. E com certeza, injete o registrador real no Adapter
- mas não em cada pequena coisa que possa precisar dele.