Injeção de Dependência
Se você já teve contato com Laravel ou AngularJS, sabe muito bem que um dos maiores motivos de orgulho desses (e de tantos outros) frameworks é a "Injeção de Dependência", ou do inglês, Dependency Injection. Imagine-se em uma reunião, o seu Product Owner pede soluções para problemas complexos, e você manda logo um "precisamos usar injeções de dependências"... É aumento salarial na hora!
Brincadeiras à parte, estou fazendo um curso de AngularJS no Udemy, e toda vez que o professor se depara com uma palavra "pomposa", ele para a aula para fazer um "big word alert".
Resolvi copiar essa ideia e mostrar como esse conceito na verdade é relativamente simples.
Dependency Injection é um Design Pattern
Assim como Closures e Decorators, o nome pode até causar certo calafrio... Don't panic! Segundo a documentação da AngularJS:
Dependency Injection (DI) is a software design pattern that deals with how components get hold of their dependencies.
Ou seja, ao invés de permitir que o seu componente de software manuseie dependências, você explicitamente passará as dependências que ele necessita.
No Stackoverflow temos o melhor exemplo da face da terra para ilustrar uma injeção de dependência. Abaixo um código sem o DI:
public SomeClass() {
myObject = Factory.getObject();
}Agora, com DI:
public SomeClass(MyClass myObject) {
this.myObject = myObject;
}Simples, não?! As dependências do seu componente ficam explícitas, fáceis de gerenciar, e seu código fica mais fácil de manter.
A Angular utiliza esse conceito para que seja possível passar para o seu controller, uma série de services necessários para a resolução de um problema:
var myApp = angular.module("myApp", []);
myApp.controller("mainController", [
"$scope",
"$log",
function($scope, $log) {
$scope.foo = "bar";
$log.log($scope.foo);
},
]);Imagine o trabalhão que seria em todo controller ter que instanciar o
serviço de $scope ou de $log?
Considerações finais
Testar um código que utiliza Dependency Injection é muito mais fácil, pois mockar as dependências e garantir o comportamente esperado pode ser feito com muito menos linhas de código.
Além disso, se o contrato de uma dependência mudar, com essa prática fica mais fácil de alterar o seu código, fazendo com que a integração entre componentes seja mais smooth.
Se você ainda duvida desse design pattern, fica a constatação: É fácil assegurar que a AngularJS não seria o framework que é hoje, sem o uso dessa prática.
Até a próxima.