Design Patterns: Entendendo os padr�es Chain of Responsibility, Command, Iterator, Mediator e Memento

Demais posts desta s�rie:
Padr�es Estruturais em Delphi
Aplicando boas pr�ticas para cria��o de objetos

Artigo no estilo Mentoring

Mentoring:

Padr�es de projeto comportamentais s�o extremamente �teis para criar softwares mais f�ceis de serem mantidos, evolu�dos, promovendo reutiliza��o de c�digo, uso de boas pr�ticas de programa��o orientada a objetos, redu��o de custos com manuten��o, j� que permitem que altera��es em um determinado sistema de software n�o quebrem outras funcionalidades, reduzindo a depend�ncia entre classes, atrav�s do uso exaustivo de abstra��es. Dessa forma, s�o �teis para serem aplicados em projetos de m�dia e larga escala.

Este artigo abordar� os padr�es de projeto comportamentais: Chain of Responsibility, Command, Iterator, Mediator e Memento. Estes padr�es ajudam a tornar sistemas de software mais f�ceis de serem mantidos e evolu�dos. Se uma aplica��o precisa ser modificada em um determinado momento, seja para manuten��o corretiva ou evolutiva para atender novas funcionalidades, este processo precisa ser feito de forma disciplinada, correta, usando padr�es, j� que o custo da manuten��o representa um porcentual elevado comparado ao custo total do sistema. Com isso, o uso de padr�es de projeto, ou Design Patterns, torna um software mais f�cil de ser mantido em longo prazo, reduzindo custos ou otimizando o retorno do investimento, apesar de exigir um maior esfor�o em um primeiro momento, durante o design do projeto a ser realizado.

Este artigo apresenta os padr�es de projeto das classes comportamentais e implementa��es de exemplos pr�ticos reais em Delphi.

Ser�o tratados os padr�es GoF, destinados a resolver problemas com opera��es, comunica��o e o relacionamento (no sentido de chamar m�todos e passar dados) entre objetos complexos, que comprometem a reutiliza��o de m�dulos do sistema e aumentam o acoplamento.

No final do artigo, apresento ainda mais um padr�o estrutural, o Proxy, de forma a complementar os padr�es vistos na edi��o anterior (Adapter, Bridge, Composite, Decorator e Facade).

Chain of Responsibility

A inten��o deste padr�o � evitar o acoplamento do remetente de uma solicita��o ao seu receptor, ao dar a mais de um objeto a oportunidade de tratar essa solicita��o. Encadear os objetos receptores, passando a solicita��o ao longo da cadeia at� que um objeto a trate.

Nesse padr�o cada objeto receptor possui uma l�gica descrevendo os tipos de solicita��o que � capaz de processar e como passar adiante aquelas que requeiram processamento por outros receptores. A delega��o das solicita��es pode formar uma �rvore de recurs�o, com um mecanismo especial para inser��o de novos receptores no final da cadeia existente.

Dessa forma, fornece um acoplamento mais fraco por evitar a associa��o expl�cita do remetente de uma solicita��o ao seu receptor e dar a mais de um objeto a oportunidade de tratar a solicita��o.

Um exemplo da aplica��o desse padr�o � o mecanismo de heran�a nas linguagens orientadas a objeto: um m�todo chamado em um objeto � buscado na classe que implementa o objeto e, se n�o encontrado, na superclasse dessa classe, de maneira recursiva.

Como benef�cio do uso do padr�o, ele permite determinar quem ser� o objeto que ir� tratar a requisi��o durante a execu��o. Cada objeto pode tratar ou passar a mensagem para o pr�ximo na cadeia. Dessa forma, o acoplamento � reduzido, dando ainda flexibilidade adicional na atribui��o de responsabilidades a objetos.

Participantes:

� Handler � define uma interface para tratar solicita��es;

� ConcreteHandler - trata de solicita��es pelas quais � respons�vel; pode acessar seu sucessor;

� Cliente � inicia a solicita��o para um objeto ConcreteHandler da cadeia;

Vamos a um exemplo pr�tico no Delphi. A Listagem 1 mostra um framework de classes que representa as classes participantes do padr�o.

� um pequeno sistema de autentica��o de usu�rios, sendo que temos tr�s classes que realizam esse processo de autentica��o: Formul�rio, Server e BancoDados. De fato, em um sistema real, normalmente realizamos a opera��o de autentica��o em v�rias camadas do nosso sistema.

Primeiram ...

Fim do trecho gratuito • continue abaixo

CONTE�DO EXCLUSIVO