Existem muitos projetos do tipo Simple Injector para várias linguagens de programação que permitem, pelo nome de uma classe, interface ou namespace, e às vezes uma pasta, registrar uma classe ou um grupo inteiro de classes unidas por este recurso em algum caso. Isso é feito com o objetivo de instanciar automaticamente um objeto sem especificar explicitamente suas dependências. Este registro de um grupo de objetos por uma característica comum no registro para fins de instanciação posterior, eu chamo registro automático de dependências.
Se você instanciar explicitamente uma classe ao registrá-la no registro de dependência, este não é o tópico deste artigo.
E o que há de errado nisso?
Neste post falarei sobre minhas frustrações com projetos que usam o registro automático de dependência. Vamos em ordem.
Tempo de execução vs tempo de compilação
Usando a ferramenta de registro automático de dependência, estamos movendo a verificação de integridade das dependências registradas para o tempo de execução. Ou seja, se na hora de lançar o programa não tivermos a implementação da interface necessária para a execução do código, saberemos na melhor das hipóteses no início da aplicação e, na pior das hipóteses - já durante a operação do sistema e pelos usuários.
Aqui está um exemplo. Se no projeto algumas classes foram registradas, digamos, por seu namespace, e você em algum ponto moveu a classe dele, então você aprenderá sobre o problema em tempo de execução. O mesmo acontecerá com o registro automático via interface, com a única diferença que mover não será um problema, mas remover a interface levará a um problema, que você aprenderá após iniciar o aplicativo.
Refatorar é muito mais complicado
Não apenas refatorar, mas também aprender o código se torna muito difícil. Isso porque ao usar o registro automático de dependências, perde-se o acesso aos recursos modernos dos ambientes de desenvolvimento, o que nos permitiria descobrir quem está usando essa classe em um clique (encontrar referência) e responder às seguintes questões:
- Posso remover esta classe?
- Posso mover esta classe para outro namespace / pasta?
etc.
Além do fato de sermos privados da oportunidade de verificar a integridade das dependências necessárias durante a compilação, qualquer refatoração é a esperança de que tenhamos um mecanismo de tempo de execução na forma de testes, verificação de árvores de dependências e assim por diante. E a esperança é que funcione. Deve-se notar que estes mecanismos não só não garantem 100% que a composição do código está correta, mas também muito mais lentos que a compilação.
Escondendo a real complexidade do sistema
Ao instanciar manualmente as classes e todas as suas dependências, você pode se assustar com a monstruosidade do arquivo no qual toda essa ação ocorrerá. Olhando para milhares de linhas de código para instanciar classes e comparando-as com uma dúzia ao usar o registro automático de dependência, eu realmente quero sucumbir à tentação e ir para o "lado negro".
Mas o que essas milhares de linhas de código de instanciação de objetos nos dizem? O fato de este módulo ser complexo, grande, e devemos pensar em estruturá-lo por meio da alocação de submódulos (que por si próprios instanciam explicitamente suas dependências) ou em dividir este módulo em vários.
Pode parecer abstrato, mas remover momentos estranhos como instanciar centenas de objetos de nossos olhos leva ao fato de que o tamanho do projeto cresce incontrolavelmente e, como resultado, perdemos o momento em que deveria ser dividido em vários projetos.
Dependências extras
Ao registrar as dependências e não controlar seu uso, mais cedo ou mais tarde chegamos a uma situação em que, no início do aplicativo, significativamente mais classes são registradas do que o necessário. A simples adição a uma pasta ou implementação de uma interface pode resultar no registro dessa classe no caso geral.
Resumo
É possível conviver com todas essas desvantagens e não percebê-las? Certo! Mas acredito que isso é desenvolver hábitos de desenvolvimento errados. A questão é que a compilação e a digitação do código são ferramentas para verificar a exatidão do sistema. Rejeitando-os, chegamos à conclusão de que o sistema se torna frágil, então os desenvolvedores têm medo de mudar qualquer coisa nele. E o medo dos desenvolvedores em alterar o código já leva ao fato de que a qualidade da base do código se degrada, após o que se torna um processo caro fazer alterações nesse código.
O que há de bom no registro automático de dependência?
E realmente, o que é bom? Proponho discutir nos comentários por que esse método ganhou popularidade. Certamente ele tem fãs entre seus leitores.