Vício em injeção de dependência?

StackOverflow https://stackoverflow.com/questions/42706

  •  09-06-2019
  •  | 
  •  

Pergunta

Existe um lado negativo?Sinto-me quase dependente disso agora.Sempre que um projeto ultrapassa um determinado tamanho, quase sinto uma reação alérgica aos padrões padrão e imediatamente reconecto-o com uma estrutura de injeção de dependência.

O maior problema que descobri é que pode ser confuso para outros desenvolvedores que estão apenas aprendendo.

Além disso, eu me sentiria muito melhor se fizesse parte da linguagem que estou usando.Embora, pelo menos para Java, existam algumas bibliotecas muito leves que são muito boas.

Pensamentos?Experiências ruins?Ou simplesmente pare de se preocupar com isso?

[EDITAR] Re:Descrição da própria injeção de dependência

Desculpe por ser vago. Martin Fowler provavelmente descreve muito melhor do que eu jamais poderia...não há necessidade de desperdiçar o esforço.

Coincidentemente, isso confirma um ponto: ainda não é amplamente praticado e pode tender a ser uma barreira ao trabalhar com equipes se todos não estiverem familiarizados com isso.

Foi útil?

Solução

Tentei descrever algumas das possíveis desvantagens em uma postagem do blog aqui: http://kevin-berridge.blogspot.com/2008/06/ioc-and-di-complexity.html

Outras dicas

O problema que tenho com o DI é o mesmo que tenho com o COM e com qualquer código parecido com:

i = GetServiceOrInterfaceOrObject(...)

O problema é que tal sistema não pode ser entendido a partir do código.Deve haver documentação em algum lugar [outro] que defina qual serviço/interface/objeto pode ser solicitado pelo serviço/interface/objeto X.Esta documentação não deve apenas ser mantida, mas também disponibilizada tão facilmente quanto a fonte.

A menos que o documento seja muito bem escrito, muitas vezes ainda não é fácil ver as relações entre os objetos.Às vezes, os relacionamentos são temporais, o que os torna ainda mais difíceis de descobrir.

Gosto do princípio KISS e acredito firmemente no uso da ferramenta certa para o trabalho.Se o benefício do DI, para um determinado projeto, superar a necessidade de escrever código compreensível, use-o.

Além disso, eu me sentiria muito melhor se fizesse parte do idioma que eu estava usando.

Para sua informação, há uma injeção de dependência muito simples e funcional como parte do JDK 6.Se você precisar de injeção de dependência simples e leve, use-a.

Usando Carregador de serviço class você pode solicitar um serviço (ou muitas implementações do serviço) baseado em uma classe:

 package dependecyinjection;  
 import java.util.ServiceLoader;  

 public abstract class FooService {  

     public static FooService getService() {  
         ServiceLoader<FooService> loader = ServiceLoader.load(FooService.class);  

         for (FooService service : loader) {  
             return provider;  
         }  

         throw new Exception ("No service");  
     }  

     public abstract int fooOperation();  

 }  

 package dependecyinjection;  
 public class FooImpl extends FooService {  
     @Override  
     public int fooOperation() {  
         return 2;  
     }  
 }

Como o ServiceLoader define as implementações de serviço retornadas?

Na pasta do seu projeto crie uma pasta chamada META-INF/serviços e crie um arquivo chamado injeção de dependência.FooService.Este arquivo contém uma linha apontando para a implementação do serviço.Nesse caso:dependecyinjection.FooImpl

Isto ainda não é amplamente conhecido.

Sou um grande fã de IO, mas vi alguns projetos com enormes arquivos de configuração xml que ninguém entende.Portanto, cuidado com a programação em xml.

Na minha opinião, as principais desvantagens são a curva de aprendizado (como você aponta) e o potencial da abstração adicional para dificultar a depuração (o que também faz parte da curva de aprendizado).

Para mim, DI parece ser mais apropriado para sistemas maiores e complexos - para aplicativos pequenos e únicos, pode resultar na arquitetura excessiva do aplicativo, basicamente, fazendo com que a arquitetura leve mais tempo de desenvolvimento para aderir do que deveria. pode compensar no valor que oferece.

Apenas pare de se preocupar com isso.É minha opinião que com o tempo as técnicas de IoC serão uma segunda natureza para a maioria dos desenvolvedores.Estou tentando ensinar os desenvolvedores aqui no trabalho sobre isso e acho difícil transmitir a mensagem porque parece muito pouco natural na maneira como sempre fizemos as coisas.que por acaso foi o caminho errado.Além disso, desenvolvedores novos em IoC e novos em um projeto que considero enfrentam dificuldades ainda maiores.Eles estão acostumados a usar o IDE para seguir a trilha de dependências para entender como a coisa toda "se encaixa".Essas informações geralmente são escritas em XML misterioso.

Você poderia adicionar um ou dois links para explicar o que realmente é a injeção de dependência, para aqueles de nós que brincam em casa?O artigo da Wikipédia é divertido, mas não muito esclarecedor.

A única desvantagem que consigo pensar é uma pequena diminuição no desempenho por meio de chamadas virtuais constantes :)

@Blorgbeard: http://www.martinfowler.com/articles/injection.html é provavelmente um dos melhores artigos sobre o assunto

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top