28 de outubro de 2009

Design Patterns com Delphi : Facade

A palavra inglesa "Facade" pode ser traduzida como fachada, isto é, a parte de uma construção que é vista por quem está do lado de fora ou a parte da frente dessa construção. Quando aplicada à Engenharia de Software, Facade denomina um Design Pattern estrutural que se propõe a trabalhar como uma fachada no programa que o implementa. Com isso, outras partes do programa enxergarão apenas o que a classe do tipo Facade expõe, sem ter que se preocupar com aspectos ligados à implementação do que é exposto.

O Facade é bastante usado para implementar o código relativo a Casos de Uso num Projeto Orientado a Objetos. Num Caso de Uso, o(s) ator(es) envolvidos interagem com o sistema, acionando operações que estão disponíveis - a "fachada". Para executar a operação solicitada, o Facade cria instâncias de um ou mais objetos de negócio conforme for necessário e transfere para eles a responsabilidade de executar tarefas menores na sequência correta, de forma que no final a operação descrita no Caso de Uso é realizada. O mesmo Facade pode encapsular a funcionalidade de um ou mais Caso de Uso, se isso fizer sentido.
Diagrama UML para Facade

A nomenclatura para as classes envolvidas no padrão Facade é a seguinte :
O Client é a classe (ou trecho de código) que faz uso da interface exposta pelo Facade, tendo conhecimento dos métodos expostos mas nada a respeito de como estão implementados. No diagrama, este participante é representado pela classe TWAtor.
O Facade é a classe principal nesse padrão. É ela quem expõe os métodos que estarão disponíveis para um Client usar. Este papel é exercido pela classe TWOperacaoCompra no diagrama anterior.
São chamadas de Subsystem Classes aquelas classes que são contidas na classe Facade. São instâncias dessas classes quem de fato executa as operações solicitadas, seja na totalidade ou cada uma colaborando com um pedaço da tarefa. As classes TWCliente, TWDocumentoCompra e TWAnaliseCredito são do tipo Subsytem Class no diagrama acima.

No diagrama acima aparece a representação UML das classes envolvidas num Caso de Uso implementado como Facade. Veja que a única relação existente entre a classe Facade e as classes de regras de negócio envolvidas é do tipo Associação. Isto é, não há herança entre elas. A classe Facade apenas contem instâncias de outras classes e as cria conforme vai precisando; para isso, essa classe é obrigada a conhecer de antemão as operações e propriedades das classes relacionadas.

Para representar esse Design Pattern em Delphi, basta declarar as classes de subsistema e incluí-las como membros na classe Facade. Elas serão instanciadas e destruídas conforme a necessidade - possivelmente dentro do próprio método que tenha que executar alguma operação nessa classe.
type
TWCliente = class
{ ... }
_Nome : String;
_Id : Double;

procedure Recuperar;
procedure Gravar;
{ ... }
end;

TWAnaliseCredito = class
{ ... }
function TemCredito (ACliente : TWCliente) : Boolean;
{ ... }
end;

TWOperacaoCompra = class
{ ... }
_Cliente : TWCliente;
_Analise : TWAnaliseCredito;

procedure VerificaCredito;
{ ... }
end;

{ ... }

procedure TWOperacaoCompra.VerificaCredito;
var lCredito : boolean;
begin;
_Cliente := TWCliente.Create;

{ recupera aqui informações do Cliente }

_Analise := TWAnaliseCredito.Create;
lCredito := _Analise.TemCredito (_Cliente);

{ ... }

_Analise.Free;
_Cliente.Free;
end;

Um outro exemplo de uso para o Facade é a criação de interface para operações de um subsistema inteiro. Imagine, por exemplo, que a análise de crédito de um Cliente em seu programa misture regras existentes no seu próprio banco de dados com verificações em um ou mais Sistemas de Proteção de Crédito. Um Facade seria uma boa solução de projeto para encapsular o acesso a todo o subsistema de Análise de Crédito já que esconderia os detalhes de implementação de cada um dos métodos de análise. Além disso, se tais métodos se encontrarem em outras bibliotecas (DLLs ou WebServices, por exemplo), o programa que fará uso do Facade não terá que se preocupar com cargas nem mapeamentos.

Mais Informações
Posts sobre Design Patterns

Nenhum comentário :

Postar um comentário

OBS: Os comentários enviados a este Blog são submetidos a moderação. Por isso, eles serão publicados somente após aprovação.

Observação: somente um membro deste blog pode postar um comentário.