Artigo Java Magazine 61 - Explicando Padr�es de Projeto � Parte 3
Artigo Java Magazine 61 - Explicando Padr�es de Projeto � Parte 3	Aprenda como utilizar Facades e Padr�es Comportamentais para reduzir complexidade de uso de subsistemas e aumentar a flexibilidade de arquiteturas.	0
Esse artigo faz parte da revista Java Magazine edi��o 61. Clique aqui para ler todos os artigos desta edi��o <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
Clique aqui para ler esse artigo em PDF. Explicando Padr�es de Projeto � Parte 3
Aprenda como utilizar Facades e Padr�es Comportamentais para reduzir complexidade de uso de subsistemas e aumentar a flexibilidade de arquiteturas
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.
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.
<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" />"	A exibi��o deste artigo foi interrompida