Termo técnico para denotar o oposto da injeção de dependência?

Isso é mais uma nomenclatura (redação técnica) do que uma questão puramente técnica. Estou tentando escrever uma proposta de refatoração (e atribuí-la a mim mesma) centrada na expansão da injeção de dependência em nosso aplicativo. Embora utilizemos o Spring para autowiring beans, ainda existem instâncias que instanciam o uso de beans MyClass obj = new MyClass(...), que podem ser totalmente injetados. Gostaria de fazer minha proposta usar nomenclatura elegante e me referir ao padrão de design oposto ao DI com um termo adequado.

"Acoplamento rígido" é um termo adequado que se destaca como antônimo de DI?

Não. O acoplamento apertado é muito mais do que o que a injeção de dependência trata.

A injeção de dependência externaliza uma decisão de implementação. Isso ajuda bastante a desacoplar, mas o acoplamento é mais do que isso.

Um bom antônimo para injeção de dependência é codificar uma dependência . Ao construir (usar novo ou usar diretamente alguma fábrica) dentro de um objeto de comportamento, você fundiu duas preocupações diferentes. Um localizador de serviço ajuda a desacoplar, mas deixa você acoplado ao próprio localizador de serviço.

O acoplamento é mais do que apenas separar construção e comportamento. Se eu tenho 101 métodos que precisam ser chamados em alguma ordem específica da classe A à classe B, estou fortemente associado. Não importa o quão maravilhosamente separados sejam construção e comportamento.

O acoplamento é uma medida da interdependência dos dois objetos. Qualquer coisa que contribua para tornar difícil fazer alterações em uma sem afetar a outra está contribuindo para o acoplamento. A injeção de dependência ajuda nisso, mas não é tudo isso.

A rigor, a Injeção de Dependência realmente não se opõe à Injeção de Dependência - e, portanto, a qualquer estratégia de gerenciamento de dependência que não seja a Injeção de Dependência.

O acoplamento [indesejado], embora não seja exatamente um problema ortogonal, pode ocorrer ou ser mitigado de qualquer maneira. Ambos são acoplados a DependencyClass:

public DependencyInjectedConstructor(DependencyClass dep) {
  dep.do();
}

public DependencyLookupConstructor() {
  var dep = new DependencyClass();
  dep.do();
}

DependencyLookupConstructoré acoplado a um particular DependencyClassneste caso. Mas, ambos estão acoplados DependencyClass. O verdadeiro mal, se houver um aqui, não é necessariamente o acoplamento, é que DependencyLookupConstructorprecisa mudar se de DependencyClassrepente precisar de suas próprias dependências injetadas ¹ .

No entanto, esse construtor / classe é ainda mais frouxamente acoplado:

public DependencyLocatingConstructor() {
  var dep = ServiceLocator.GetMyDoer();
  dep.do();
}

Se você estiver trabalhando em C #, o acima permitirá que você ServiceLocatorretorne qualquer coisa quando GetMyDoer()for chamada, desde que possua o do()que a DependencyLocatingConstructorpossui do(). Você obtém o benefício da validação de assinatura em tempo de compilação sem precisar ser acoplado a uma interface completa ² .

Então, escolha seu veneno.

Mas, basicamente, se houver um "oposto" concreto da injeção de dependência, seria outra coisa no campo das "Estratégias de gerenciamento de dependência". Entre outros, se você usasse um dos seguintes itens na conversa, eu o reconheceria como sendo NÃO injeção de dependência:

• Padrão do Localizador de Serviço
• Localizador / Local de Dependência
• Construção direta de objeto / dependência
• Dependência oculta
• "Injeção sem dependência"

^{1. Ironicamente, alguns dos problemas que o DI resolve em níveis mais altos são como resultado do uso excessivo do DI nos níveis mais baixos. Tive o prazer de trabalhar em bases de código com complexidade desnecessária em todo o mundo, como resultado de acomodar vários lugares onde essa complexidade realmente ajudou ... Sou admitidamente influenciado por más exposições.}

^{2. O uso da localização do serviço também permite que você especifique facilmente diferentes dependências do mesmo tipo por sua função funcional a partir do código de chamada , embora ainda seja bastante independente sobre como a dependência é construída. Suponha que você precise resolver Userou IUserpara diferentes propósitos: por exemplo, Locator.GetAdministrator()versus Locator.GetAuthor()- ou o que for. Meu código pode solicitar o que ele precisa funcionalmente, mesmo sem saber quais interfaces ele suporta.}

Eu não sei que há específica, terminologia da indústria amplamente aceito, mas as alternativas que vêm à mente incluem a criação interna exemplo , a criação de dependência interna , dependências locais ou dependências escopo localmente .

Eu iria com o encapsulamento de dependência . Isso expressa que a dependência está bloqueada em vez de visitar e sair novamente.