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.

Vamos continuar trabalhando no exemplo passado, lembrem-se do nosso sistema de cobrança.

Calcular apenas o juros não é suficiente, precisamos de muitas outras regras para chegar ao valor final que teriamos que cobrar de um devedor. Mas não podemos misturar a regra de calculo de juros de um banco com a regra de desconto do outro.

Para nos ajudar nesse tipo de situação podemos utilizar o padrão Abstract Factory. Como vimos no artigo factories ele serve para criar “famílias” de objetos. Então podemos implementar o modelo abaixo:

Nesse caso a nossa “Calculadora” conhece uma classe ques será responsável por criar todas as outras regras, e teremos que implementar uma dessas para cada banco que venha a entrar em nossa carteira de cobrança, mas não corremos o risco de alterar a regra de um banco para fazer a manutenção ou substituição da regra de outro.

Bom por enquanto é isso, e desculpem a demora na postagem.

Aceito sugestões para o próximo tema e criticas sobre o que já foi pro ar.

Imaginem um sistema que é utilizado por uma empresa de cobrança.

Nele precisaremos estar prontos para trabalhar com diversas carteiras de cobrança, cada uma de um banco ou empresa diferente e com regras totalmente distintas entre elas, algumas promoções malucas e uma série de outros fatores.

Num cenário como esse devemos conseguir desacoplar as regras principais do negócio das regras específicas de cada carteira de cobrança, assim geramos o menor impacto possível quando cada um dos clientes da empresa mandar uma nova regra de cobrança (e podem acreditar isso é MUITO frequente).

Para simpificar o exemplo imagine que apenas a regra de calculo de juros possa variar de uma carteira para outra. Podemos nesse caso utilizar um modelo parecido com o abaixo.

Nosso sistema deverá trabalhar sempre com as classes CalculadoraCobranca e CalculadoraJuros, no entanto ireos encapsular as regras de cada banco dentro das classes concretas JurosBancoX e JurosBancoY, que serão criadas pelos seus contrutores concretos.

Ainda haerá a necessidade de alguma outra parte do sistema saber qual das classes concretas utilizar e isso certamente será resolvido pelas sua camada de aplicação, mas a regra do seu negócio fica isolada e pode ser testada e modificada muito mais facilmente do que se você utilizasse uma estrutura condicional na classe que calcula os juros.

Até a próxima.

Vou começar escrevendo aqui sobre o conjunto de Design Patterns que mais tenho visto gerar confusão, não sei se isso é verdade para todos, mas aparentemente existem alguns ilustres desconhecidos que são o tempo todo citados e nunca compreendidos.

Em primeiro lugar não há um padrão Factory (ao menos não no livro Design Patterns), eles são dois, com objetivos distintos. São eles:

Factory Method:

Abstract Factory:

Como podemos ver os modelos estruturais são bastante distintos.

A idéia é mais ou menos a seguinte:

• Com Factory Method, iremos preparar um cliente para gerar classes concretas que ele não tem conhecimento, ou seja iremos desacoplar a aplicação do conhecimento da classe concreta e deixaremos ele dependente apenas das abstrações, isso irá nos possibilitar escolher as concretizações em tempo de execução.
• Com Abstract Factory, iremos fazer com que famílias de objetos sejam sempre instânciadas juntas, evitando erros de instanciação.

Além desses dois padrões posso citar a apresentação de Padrão Factory do livro Refatoração para Padrões, onde o autor Joshua Kerievsky, chama de Factory “qualquer classe que possua um método de criação, seja estático ou não”, isso significa que tanto Factory Method quanto Abstract Factory utilizam Factorys, mas lembrem-se que nem toda Factory é um desses dois padrões.

Nos próximos posts irei detalhar mais esses padrões e colocar alguns exemplos mais palpáveis.

Durante os ultímos meses tenho acompanhado e participado de discussões sobre processos de software, sobre qualidade de código e modelos, sempre surgindo grandes discssões entre processos ágeis contra o RUP (sim, mudam de nome disfarçam mas espancam o pobre coitado).

Tenho visto muita coisa acontecendo e chegou minha vez de subir nesse palco e colocar minha idéias para fora.

Nesse blog tentarei colocar o máximo de informação que eu tiver sobre tudo o que envolve o bom desenvolvimento de software e espero que possamos ter discussões calorosas sobre tudo o que for colocado aqui.

Então vamos lá, vamos criar juntos uma grande força para desenvolver software com cada vez mais qualidade e cada vez mais rápido, da forma como nossos clientes gostam.