Deve-se usar Injeção de Dependência mesmo que a classe seja usada apenas uma vez? [duplicado]

14

Durante uma revisão de código, comecei a ter um dilema sobre o uso de injeção de dependência ou não. Eu gostaria de ouvir seus pensamentos, porque esse é um tema contínuo e ajudaria nas futuras revisões de código também.

Antes de começar, quero dizer que, do meu conhecimento, a DI é usada principalmente para gerenciamento de dependências e melhor, muito mais fácil, para testes de unidade (corrija-me se estiver errado, por favor).

Agora, aqui está o cenário:

Esta é a classe que será usada como dependência apenas uma vez e provavelmente para sempre. Significa que vai ficar assim por um tempo e nenhuma outra classe vai usá-lo.

Razão é porque é uma refatoração de algum código legado e não havia muito a ser feito, mas para separá-lo em outra classe, pelo menos como um primeiro bom passo, para seguir o SRP .

Além disso, outra coisa é que o hipotético doSomethingImportant () atinge o banco de dados.

public SomeClass
{
   public Object doSomethingImportant()
   {
      ...
   }
}

Com base nessas informações, você acha que não há problema em aumentar a dependência da outra classe em oposição ao uso da DI, uma vez que:

O tipo de argumento de gerenciamento de dependência cai porque só será usado uma vez.

e

O teste de unidade também cai porque eu preferiria fazer um teste de integração ou aceitação para ver como o método está interagindo com o banco de dados em um aplicativo da vida real.

public SomeOtherClass
{
   private readonly SomeClass _someClass = new SomeClass();

   public Object doSomethingImportantUsingDependency()
   {
      ...
   }
}

Eu estava pessoalmente inclinado a fazer DI, porque é considerado uma boa prática, mas por um segundo senti que estava seguindo as regras de forma cegante e não pensando sobre isso, pois sempre há exceções à regra.

Quais são seus pensamentos sobre isso? Eu adoraria ouvir.

PS: Eu não acho que essa é uma pergunta genérica "quando devo usar DI" porque é muito específica para essa situação em particular quando os testes de unidade são inúteis e a classe vai ser usada apenas uma vez que não há necessidade de centralizá-lo para o gerenciamento de dependências (mesmo que seja uma boa prática em geral).

    
por AvetisG 08.04.2015 / 17:23
fonte

4 respostas

13

Em C #, é trivial fornecer injeção de dependência opcional sem se ligar à sua dependência com muita força:

public class SomeOtherClass {
    private readonly ISomeClass _someClass;

    public SomeOtherClass(ISomeClass dependency = null) {
        _someClass = dependency ?? new SomeClass();
    }
}

(ou você pode tornar os construtores explícitos se sua empresa não gostar dos parâmetros padrão)

Na minha experiência, "oh nunca vamos precisar de outro" é ingênuo. Mudanças nos negócios. Mudanças tecnológicas. Torne as dependências flexíveis.

E esse tipo de coisa alcança o equilíbrio certo entre usabilidade (sim, você quase sempre usará a comum / padrão) e flexibilidade (mas o coordenador está lá se você precisar) - tudo com uma linha simples e agradável de código, enquanto também fornece alguma semelhança de correção de erros de robustez. É tão trivial e claramente benéfico, não há razão para não fazê-lo para o caso simples / direto.

    
por 08.04.2015 / 17:35
fonte
11

Existe um princípio de desenvolvimento ao longo das linhas de DRY e SOLID chamado YAGNI, que foi projetado para ajudar a otimizar seus esforços de desenvolvimento para fazer as coisas e não ficar paralisado com a indecisão sobre o que fazer.

Se mais tarde descobrir que precisa melhorar sua turma, você o fará. YAGNI diz para não se preocupar tanto com isso agora porque você provavelmente não precisará gastar esse esforço extra. Faça isso, volte se realmente precisar.

Alguns dizem que é o oposto do SÓLID, mas na verdade é sobre negociar todos os fatores envolvidos no desenvolvimento, você não tem tempo ou recursos infinitos (e o código 'perfeito' nunca é IMHO).

Então, aqui, você diz que não precisa de complexidade de DI ... então, há sua resposta. Não coloque isso. Mova-se para todas as outras coisas que você tem que fazer.

    
por 08.04.2015 / 17:41
fonte
5

Se você não aplicar DI, desde que você realmente não precise (nem mesmo para testes unitários), nada de ruim acontecerá. O código não se torna propenso a erros, "excessivamente complicado" ou de difícil manutenção. E se você decidir refatorar a dependência mais tarde, provavelmente não será muito mais difícil do que fazê-lo agora. Esse é um caso em que o princípio YAGNI se aplica.

No entanto, o que você deve verificar é se você tem certeza de que realmente não deseja testar SomeOtherClass da unidade isoladamente de SomeClass e se a dependência imposta sobre os assemblies em que SomeOtherClass e SomeClass ao vivo não se tornará um problema. Se você tem 100% de certeza de que a resposta às perguntas anteriores é "sim", então você pode ignorar a DI.

    
por 08.04.2015 / 20:25
fonte
0

A resposta como a maioria das coisas é "depende".

Se você quiser testar a funcionalidade da unidade em doSomethingImportantUsingDependency , precisará injetar a dependência.

No entanto, se tudo que o doSomethingImportantUsingDependency faz for algum mapeamento de propriedade do resultado da sua chamada ao banco de dados, então seria pragmático não incomodar.

Se alguma outra classe depender de SomeOtherClass , você poderá sempre injetar essa classe.

    
por 08.04.2015 / 17:37
fonte