Curso introdutório gratuito de Ruby On Rails

Deixem-me dar essa notícia antes que eu esqueça novamente

Lembram do curso gratuito de Ruby, ministrado pelo indiano Satish Talim? Um amigo dele resolveu seguir a onda, e abriu um curso de Ruby on Rails. Seu nome é Sunil Kelkar. O curso terá início no dia 12 de abril.

Tá esperando o quê? Matricule-se!

Enrolação de dependências – parte II

Antes de prosseguir, leia: http://cabritin.wordpress.com/2008/03/06/enrolacao-de-dependencias-parte-i/

Inversion of Control – IoC (inversão de controle)

Podemos definir inversão de controle como sendo simplesmente a transferência de uma ou mais responsabilidades para uma entidade exterior, que decidirá o momento e a ordem de ocorrência dos eventos inerentes a essas responsabilidades. Esse princípio já existe há muito tempo, e não se restringe somente ao mundo da computação.

Por exemplo, se você tem uma conta pra pagar, você se encaminha ao banco e paga. Ou seja, é sua responsabilidade controlar o evento “pagar minha conta”, e é você quem toma a decisão do momento em que deseja pagá-la. Porém, se você não tem tempo e pede para sua irmã efetuar o pagamento para você, você transferiu a responsabilidade sobre o evento “pagar minha conta” para ela. Assim, ela é quem vai tomar a decisão do momento de pagar a conta, lhe devolvendo o comprovante de pagamento.

Uma expressão famosa que ilustra a IoC é enunciada pelo princípio de Hollywood: “don’t call us, we call you”.

Dentro da computação, uma aplicação do conceito de inversão de controle pode ser encontrada em ferramentas baseadas em programação orientada a eventos, como o Delphi e o Visual Basic. Um programa orientado a eventos consiste, muito simploriamente, em um laço principal com duas seções: detecção e tratamento de eventos:

main()
    repita
        // Detecta eventos registrados pelo programador
        detecte_eventos()
        // Executa os eventos registrados
        trate_eventos()
    fim
fim

Quando desenvolvemos aplicações gráficas usando as IDEs referenciadas, utilizamos um framework de criação e gerenciamento de janelas e eventos (no Delphi para Win32, por exemplo, esse framework é o VCL, que significa Visual Component Library) , e esse framework fica responsável por executar o laço acima. Tudo o que precisamos fazer é definir os eventos em nosso programa e registrá-los; nós não somos mais responsáveis por executá-los. As IDEs fornecem inúmeros recursos para facilitar o registro desses eventos.

Note que, se implementarmos o laço por nós mesmos, não estamos invertendo controle de coisa alguma! Utilizar programação orientada a eventos não implica necessariamente em utilizar inversão de controle. Para isso, devemos usar alguma entidade externa – um framework, ou uma biblioteca – que execute o laço para nós e cuide das questões inerentes à detecção e tratamento de eventos.

Podemos encontrar outra aplicação de inversão de controle no paradigma orientado a objetos. Sim, estamos falando da injeção de dependências, um tipo de inversão de controle onde a responsabilidade a ser “invertida” é o processo de obter dependências. Será o tema da próxima parte deste artigo, onde retomaremos o exemplo desenvolvido na primeira.

Até lá.

Enrolação de dependências – parte I

Uma das metas que mais se busca em orientação a objetos é diminuir o acoplamento entre os componentes da aplicação (componentes aqui são classes, pacotes, camadas, etc). E uma das formas mais eficientes de se fazer isso é utilizando injeção de dependências. Mas como toda boa prática que se torna popular, ela não podia deixar de gerar confusão entre aqueles que tentam utilizá-la. E também não podiam deixar de aparecer os “entendidos no assunto”: vomitam as palavras sem nem saber o que é e para quê serve esse recurso.

As expressões que estão na boca do povo nem sempre são as mais adequadas. Muitos se referem à prática em questão como “inversão de dependências”. Depois aparece outro que tenta corrigir, dizendo que “inversão de dependências não existe”. E chega outro falando de uma tal de “inversão de controle”. No final das contas, muitos acabam achando que as três expressões são sinônimas.

Pois bem. Vamos tentar desmistificar as coisas!

Inversão de dependências

Vamos supor que estamos desenvolvendo um sistema de cadastro de funcionários de uma empresa, onde os funcionários podem ser de dois tipos: gerentes e empregados.

Tentaremos uma primeira abordagem, ilustrada pelo diagrama de classes abaixo. De acordo com ele, uma empresa possui um ou mais gerentes e um ou mais empregados.

Na figura, podemos verificar que a classe Empresa depende claramente de classes concretas, que são Gerente e Empregado. Ou seja, sempre que quisermos uma instância de Gerente na classe Empresa, teremos que obtê-la usando new Gerente(). Isso tem um lado ruim, pois se essas classes mudarem a forma como são instanciadas (modificações nos parâmetros dos construtores, por exemplo), teremos fatalmente que mexer no código da classe Empresa. Sem falar nas alterações decorrentes de um novo tipo de funcionário sendo adicionado.

Diante deste cenário, vamos enunciar o princípio da inversão de dependências:

“Componentes de alto nível não devem depender de componentes de baixo nível. Ambos devem depender de abstrações.”

Componentes de alto nível são assim chamados porque seu comportamento depende de outros componentes, os de baixo nível. No diagrama acima, Empresa é um componente de alto nível, enquanto Gerente e Empregado são de baixo nível.

E agora, como aplicar esse princípio ao diagrama acima? Simples. Posicione uma abstração entre os componentes de alto nível e os de baixo nível. Assim, ambos dependerão de abstrações:

E pronto! O princípio da inversão de dependências está aplicado. Mas qual a vantagem? Uma delas é que, a partir de agora, a classe Empresa não conhece nada sobre as implementações de Funcionario; sabe apenas que lida com funcionários, não importando se são gerentes ou não. Ou seja, desacoplamento.

Mas ainda temos um problema. Antes, quando Empresa dependia de funcionários concretos, eu os instanciava diretamente usando o operador new. E agora? A inclusão dessa interface não retirou o meu problema; eu ainda preciso instanciar os funcionários usando new. E isso significa dizer que as classes ainda estão acopladas!

Ahhhhhhhh, garotinho… É exatamente nesse ponto que entra a Injeção de Dependências. Nós não criaremos as instâncias; alguém as criará para nós. Mas isso é assunto para a segunda parte desse artigo.

Até lá.