Este é um post disponível para assinantes MVPou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Artigo Java Magazine 61 - Explicando Padrões de Projeto – Parte 3
Artigo da Revista Java Magazine Edição 61.
Você não gostou da qualidade deste conteúdo?
(opcional) Você gostaria de comentar o que não lhe agradou?
Explicando Padrões de Projeto – Parte 3
Soluções padronizadas para problemas recorrentes
Aprenda como utilizar Facades e Padrões Comportamentais para reduzir complexidade de uso de subsistemas e aumentar a flexibilidade de arquiteturas
De que se trata o artigo:
Uso dos padrões Facade, Template Method e Strategy. Neste artigo o Facade foi explicado e comparado em situações diferentes. Comparações e indicações de frameworks que utilizam o padrão Template Method foram utilizadas para facilitar seu entendimento, e por fim o Strategy foi abordado e exemplificado.
Para que serve:
Este artigo oferece informações ao desenvolvedor que podem auxiliá-lo a simplificar o acesso a subsistemas, além de desenvolver aplicações que sejam mais flexíveis. Utilizar os padrões abordados auxilia na busca por códigos mais simples, elegantes e reutilizáveis.
Em que situação o tema é útil:
Além de ser considerado uma boa prática de programação, o uso de Facades para reduzir o acoplamento e a complexidade para utilização de subsistemas aumenta a manutenibilidade do sistema. O Template Method é útil quando se quer dar a chance, ou exigir, de um desenvolvedor que certas customizações sejam feitas. Strategy exibe sua utilidade toda vez em que se faz necessário implementar diversas variações de comportamentos ou de algoritmos que podem ser utilizados por meio de uma interface padrão.
Explicando Padrões de Projeto – Parte 3:
Quando um sistema é composto por diversos subsistemas complexos é possível simplificar o acesso às funcionalidades utilizando Facades. Facades provêem interfaces simplificadas para isolar e facilitar o acesso a este tipo de sistemas.
Freqüentemente desenvolvedores e arquitetos desejam que a implementação de certas operações sejam delegadas, ou influenciadas, por desenvolvedores finais. Uma solução conhecida para este problema é definida no padrão Template Method, que permite definir partes do código que devem ser obrigatoriamente sobrescritas ou, ainda permitir, mas não obrigando a, que partes sejam modificadas pelo desenvolvedor.
Quando se faz necessário variar o comportamento de um sistema, ou de um algoritmo, mantendo uma interface padrão, é possível substituir condicionais encadeadas (ifs) que seriam utilizadas para escolher o comportamento adequado implementando o padrão Strategy. Desta forma o resultado é a produção de arquiteturas e códigos mais elegantes, eliminando o encadeamento de tais condicionais do código.
Nos três casos é possível observar ganhos do ponto de vista de Orientação a Objetos. Estes padrões, por exemplo, visam à redução de acoplamento. No caso de Template Method e Strategy há também ganhos no que se refere à coesão, uma vez que cada classe e/ou subclasse desempenham papéis mais bem definidos. Conseqüências decorrentes do uso destes padrões podem ser localizadas nos quadros resumo de cada um deles.
Padrões de Projeto: Trilhando o caminho
No artigo anterior desta série, os padrões de criação Abstract Factory e Factory Method foram apresentados. Neste artigo trabalharemos os padrões Façade, Template Method e Strategy, que constituem parte importante do catálogo de padrões proposto pela GoF. O uso destes padrões pode poupar trabalho, além de privilegiar a flexibilidade da arquitetura de sistemas.
Padrão: Façade
O principal objetivo de um Façade é facilitar o uso de um ou mais componentes de software. Isso é realizado por meio da construção de uma “fachada” que isola a aplicação cliente de toda a complexidade de um subsistema. O padrão Façade define uma interface de alto-nível que simplifica as chamadas a subsistemas complexos.
Basicamente, o padrão Façade propõe uma forma mais simples de interagir com o sistema que o modelo atual oferece. Claro, por ser mais simples, esta abordagem funciona quando o cliente precisa utilizar apenas um subconjunto dos recursos oferecidos pelo subsistema e/ou adaptá-lo para uso de uma maneira particular em suas necessidades.
Imagine o cenário: na empresa Acme Co. há uma plataforma complexa de APIs de cobrança, mas clientes externos precisam utilizar apenas parte dos seus recursos. Em vez de conhecer toda a complexidade da API de cobrança, seria adequado que os desenvolvedores disponibilizassem uma interface simples o suficiente para chamar os métodos que realizam as tarefas necessárias. A idéia é criar uma “fachada” que esconda toda a complexidade interna das APIs de cobrança. Dessa forma, os clientes da API de cobrança da Acme Co. ficarão agradecidos. A Figura 1 ilustra a solução do problema.
Este é um post disponível para assinantes MVPou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Graduado pela universidade Mackenzie, pós-graduado pela PUC, mestrando em Engenharia de Software e membro do grupo de pesquisa LabMed (Laboratório de Medidas de Arquitetura) pelo Instituto de Pesquisas Tecnológicas do Estado de São Paulo – IPT. Possui as certificações SCJA e SCJP. Instrutor na Globa...
