Arquitetura de Software

Depois de uma longa pausa estamos de volta.

Em vários sistemas em que já tive a oportunidade de trabalhar um problema comum é o uso de componentes de terceiros.

Para que nosso trabalho seja realizado mais rapidamente muitas vezes acabamos comprando componentes ou utilizando um que seja de uso livre.

Acho essa uma das coisas mais acertadas a se fazer, acho que sempre ouvimos por ai para não tentar “reinventar a roda”. Essa é uma das melhores idéias que podemos seguir, já que como todo desenvolvedor sabe a cada dia que passa temos que entregar mais trabalho em menos tempo e com mais qualidade (quem disse que era fácil???).

Mas qual o problema afinal?

Bom acontece que as vezes precisamos trocar de fornecedor. As vezes aquela biblioteca livre que era fantástica quando decidimos usar não foi mais atualizada.

A verdade é que acabamos por não pensar muito nas consequências de um componente não ter mais novas atualizações, e quando decidimos por usá-los acoplamos nossos sistemas aos componentes escolhidos.

Para resolver isso podemos usar o padrão “Adapter” diferente dos dois anteriores que mostrei aqui este não é mais um padrão de criação, mas sim estrutural.

Vamos dar uma olhada:

Exemplo do padrão Adapter

Podemos ver 4 componentes nesse padrão:

• Client: Esse é o nosso sistema efetivamente;
• Adaptee:  Representa o componente de um terceiro;
• Target: É uma classe abstrata ou uma interface que o nosso sistema irá conhecer, é através dela que iremos desacoplar nosso sistema do componente que escolhermos usar;
• Adapter: Essa classe nós faremos implementar a interface Target e a partir dela chamaremos o componente Adaptee.

Ao invés de usar o componente diretamente agora nós temos 2 novas classes no nosso sistema, e isso é o que fará o sistema não ser vulnerável as alterações de um componente.

A partir de agora assim que acharmos um componente melhor basta reimplementar a classe Adapter e substituir o componente, sem ter que reescrever todos os pontos do sistema que usam funcionalidades do componente escolhido.

Vamos tentar um exemplo real:

Exemplo do padrão Adapter

Bom imaginem que nosso sistema é um editor de texto, ou uma ferramenta de envio de e-mails.

Uma das funcionalidades que nosso sistema terá é a habilidade de traduzir textos.

Mas vamos lá você não vai perder seu tempo e desenvolver um componente que faça a análise do texto e ainda criar um dicionário que contenha milhares de palavras traduzidas vai?

Para economizar tempo deixamos o trabalho de tradução para quem sabe faze-lo, digamos que você encontre um componente que faça chamadas para a API do google translate por você.

É isso que o modelo acima faz, nosso sistemas só tem que saber que se ele chamar “Tradutor.translate” ele terá o texto traduzido. Quem faz a chamada real é a implementação dessa classe abstratada (TradutorGoogle).

Mas e se acharmos um componente que usa as APIs do BabelFish (da Yahoo)?

É só implementar uma classe TradutorBabelFish que usa esse novo componente e fazer o seu sistema passar a usa-la.

Vejamos:

Exemplo do padrão Adapter com 2 implementações

Se prestarem atenção o componente BabelFish usa um parâmetro adicional para indicar para qual língua ele deve traduzir o texto recebido, para o nosso editor isso simplesmente não importa. Basta passarmos um valor default que represente a língua que nosso sistema usa e pronto, tudo resolvido.

Não importa se nosso editor usa o componente Tradutor em 1 ou em 1000 lugares diferentes, essa classe não será alterada, apenas criamos um nova herdeira dela e passamos a usa-la.

Então é isso, devemos sempre procurar componentes prontos para usar no nosso dia a dia, mas devemos usá-lo de maneira que traga mais benefícios do que problemas e essa é uma forma.

Fico por aqui e aceito sugestões para os próximos posts.