Marcelo Madeira

Baixo Acoplamento

fevereiro 10, 2009 às 1:19 pm | Publicado em Desenvolvimento, Java | 2 Comentários

Programar é uma tarefa ardua e programar um código que siga os bons princípios é mais ainda. Na correria do dia a dia, acaba-se esquecendo das boas práticas e o resultado é um código “macarrônico” totalmente sem padrão. Um colega sempre dizia “Programar bem é uma arte!!!”.

Neste post será abordado um princípio muito importante para sistemas orientados a objeto, o desacoplamento do código. Todo o artigo será baseado no estudo de caso de uma pequena API para envio de malas diretas.

Abaixo segue a modelagem do problema:

A classe mala direta é responsável por enviar uma mensagem a um grupo de destinatários. Para isso, ela utiliza do componente “EnviadorEmail”. Segue a implementação da mesma:

 

O exemplo acima demonstra um exemplo de código altamente acoplado. Isto se caracteriza pela utilização direta de uma classe concreta (new EnviadorEmail()), acarretando em um problema muito grave: Torna-se impossível trocar a forma de envio da mala direta em tempo de execução pois o código está altamente acoplado com o componente EnviadorEmail.

Desacoplando o código:

Desacoplar um código consiste em montar um design que o deixe mais fléxivel a mudanças. Programar um código desacoplado garante uma maior qualidade e facilita futuras mudanças.

Erich Gamma, o criador do Eclipse, JUnit e co-autor do famoso livro “Padrões de Projeto” disse em uma entrevista: “Program to an interface, not an implementation”.

Programar para interface deixa o código mais flexível, permitindo trocar a implementação de um componente em tempo de execução. Refatorando o nosso design para utilizar interfaces:

Refatorando o código da MalaDireta:

Quando um código depende de uma interface, pode-se decidir em tempo de execução qual a implementação será utilizada. Um exemplo pode ser verificado na imagem abaixo:

Porém ainda existe um pequeno acoplamento no método enviar. O método ainda precisa dar o new em uma implementação, o que o torna fortemente acoplado a ela. O ideal é que outro componente tome a decisão de qual implementação criar. A função da MalaDireta é enviar sua mensagem. Não é sua responsabilidade saber de qual forma.

Factory

O design pattern Factory tem como função separar a lógica de criação de objetos em um outro componente (fábrica). No exemplo acima, pode-se ter o EnviadorFactory. Uma forma de implementação do factory pode ser visto abaixo:

Refatorando a classe MalaDireta para utilizar a fábrica:

Utilizando a fábrica foi possível separar a lógica de criação da forma de envio das malas diretas, porém o método agora ficou acoplado com a fábrica. Utilizar fábricas solucionou apenas parte do problema, como desacoplar totalmente o código da MalaDireta???

Inversão de Controle

Martin Fowler escreveu em seu site um artigo muito interessante sobre Inversão de Controle (IoC). O artigo levanta uma interessante discussão: Qual controle da aplicação está sendo invertido???

A inversão de controle consiste em uma mudança na forma como são criadas as dependências dos objetos. No exemplo utilizando fábricas, o método “pede” para a fábrica uma dependência. Na visão da IoC, não é mais o código que pede por uma dependência, ele apenas declara que precisa de determinado componente e ele é disponibilizado.

Seguindo este princípio, Martin Fowler questiona se o nome correto para a Inversão de Controle não seria Injeção de Dependência. Segundo ele, a mudança afeta a forma como são gerenciadas as dependêcnias que agora são injetadas nos objetos, eliminando assim o uso da palavra new no código:

A classe acima declara em seu construtor que precisa de uma implementação de IEnviador. Ou seja, alguém irá “injetar” esta dependência. O método enviar não sabe pra onde está enviando sua mensagem. O código está totalmente desacoplado!!!!

Exemplo de um código que utiliza a MalaDireta:

 

Com um código totalmente desacoplado, fica fácil criar testes unitários e consequentemente aumenta a qualidade do código.

Infelizmente não são todos os desenvolvedores que possuem esta preocupação. Mas espero que este pequeno artigo tenha gerado uma grande reflexão sobre como construir componentes de verdade.

Sempre que for codificar, lembre-se da frase: “Programe para interfaces e não para implementações!”.