No exemplo, as classes concretas dizem respeito à necessidade de aprovação de documentos e cada uma delas aplica suas próprias regras de acordo com o poder de decisão necessário para efetuar uma aprovação.
type
TWAprovacao = class
{ ... }
protected
_Sucessor: TWAprovacao;
{ ... }
procedure SetSucessor (aSucessor: TWAprovacao);
function PrecisaAprovacao (aDoc: TWDocumento) : boolean;virtual;abstract;
procedure RequisitaAprovacao (aDoc: TWDocumento);virtual;abstract;
end;
TWAprovacaoBasica = class(TWAprovacao)
{ ... }
function PrecisaAprovacao (aDoc: TWDocumento) : boolean;override;
procedure RequisitaAprovacao (aDoc: TWDocumento);override;
end;
TWAprovacaoGerente = class(TWAprovacao)
{ ... }
function PrecisaAprovacao (aDoc: TWDocumento) : boolean;override;
procedure RequisitaAprovacao (aDoc: TWDocumento);override;
end;
Veja que na classe base TWAprovacao há um membro (variável) chamado _Sucessor. Esse membro representa o próximo nível a ser consultado na hierarquia de responsabilidades. Assim, quando as regras de uma classe não permitem que ela tome uma decisão, ela repassa para seu "sucessor" a responsabilidade de decidir - daí o nome de Cadeia de Responsabilidade para o Pattern. As funções que verificam a aprovação em cada classe, então, devem levar o sucessor em conta:TWAprovacao = class
{ ... }
protected
_Sucessor: TWAprovacao;
{ ... }
procedure SetSucessor (aSucessor: TWAprovacao);
function PrecisaAprovacao (aDoc: TWDocumento) : boolean;virtual;abstract;
procedure RequisitaAprovacao (aDoc: TWDocumento);virtual;abstract;
end;
TWAprovacaoBasica = class(TWAprovacao)
{ ... }
function PrecisaAprovacao (aDoc: TWDocumento) : boolean;override;
procedure RequisitaAprovacao (aDoc: TWDocumento);override;
end;
TWAprovacaoGerente = class(TWAprovacao)
{ ... }
function PrecisaAprovacao (aDoc: TWDocumento) : boolean;override;
procedure RequisitaAprovacao (aDoc: TWDocumento);override;
end;
function TWAprovacaoBasica.PrecisaAprovacao (aDoc: TWDocumento) : boolean;
begin;
Result := true;
{ Regra básica para determinar se o documento precisará de uma aprovação }
if (aDoc.Valor > 1500) then begin
if (_Sucessor <> Nil) then
Result := _Sucessor.PrecisaAprovacao (aDoc);
end
else
Result := false;
end;
procedure TWAprovacaoBasica.RequisitaAprovacao (aDoc: TWDocumento);
begin;
if PrecisaAutorizacao then begin
{ Executa ações necessárias para obter aprovação básica. Exemplos: envio de email, gravação no BD, etc}
end;
end;
function TWAprovacaoGerente.PrecisaAprovacao (aDoc: TWDocumento) : boolean;
begin;
Result := true;
{ Regra aplicada a gerentes para determinar se o documento precisará de uma aprovação }
if (aDoc.Valor > 8000) then begin
if (_Sucessor <> Nil) then
Result := _Sucessor.PrecisaAprovacao (aDoc);
end
else
Result := false;
end;
procedure TWAprovacaoGerente.RequisitaAprovacao (aDoc: TWDocumento);
begin;
if PrecisaAutorizacao then begin
{ Executa ações necessárias para obter aprovação para Gerentes. Exemplos: envio de email, gravação no BD ou outra específica. }
end;
end;
A chave para o funcionamento da solução está na forma como o encadeamento é montado. Neste ponto, invariavelmente teremos que utilizar algum dos padrões dedicados à flexibilizar a criação de instâncias de classes, tal como o Factory Method:begin;
Result := true;
{ Regra básica para determinar se o documento precisará de uma aprovação }
if (aDoc.Valor > 1500) then begin
if (_Sucessor <> Nil) then
Result := _Sucessor.PrecisaAprovacao (aDoc);
end
else
Result := false;
end;
procedure TWAprovacaoBasica.RequisitaAprovacao (aDoc: TWDocumento);
begin;
if PrecisaAutorizacao then begin
{ Executa ações necessárias para obter aprovação básica. Exemplos: envio de email, gravação no BD, etc}
end;
end;
function TWAprovacaoGerente.PrecisaAprovacao (aDoc: TWDocumento) : boolean;
begin;
Result := true;
{ Regra aplicada a gerentes para determinar se o documento precisará de uma aprovação }
if (aDoc.Valor > 8000) then begin
if (_Sucessor <> Nil) then
Result := _Sucessor.PrecisaAprovacao (aDoc);
end
else
Result := false;
end;
procedure TWAprovacaoGerente.RequisitaAprovacao (aDoc: TWDocumento);
begin;
if PrecisaAutorizacao then begin
{ Executa ações necessárias para obter aprovação para Gerentes. Exemplos: envio de email, gravação no BD ou outra específica. }
end;
end;
function GetAprovacaoFromFactory (AUsuario: TWUsuario): TWAprovacao;
var lUltSucessor, lAux : TWAprovacao;
begin
{ A aprovação básica sempre existe e é o ponto de entrada das aprovações }
Result := TWAprovacaoBasica.Create;
lUltSucessor := Result;
if AUsuario.TipoCargo >= tcGerente then begin
lAux := TWAprovacaoGerente.Create;
lUltSucessor.SetSucessor (lAux);
lUltSucessor := lAux;
end;
{ Cria sucessivamente a hierarquia de aprovações ... }
if AUsuario.TipoCargo >= tcDiretor then begin
lAux := TWAprovacaoDiretor.Create;
lUltSucessor.SetSucessor (lAux);
lUltSucessor := lAux;
end;
{ ... }
end;
Observe que a montagem da cadeia de responsabilidades começa pelo nível hierárquico mais baixo - que está sempre presente - e vai crescendo conforme aumenta o cargo do Usuário que está solicitando a aprovação. var lUltSucessor, lAux : TWAprovacao;
begin
{ A aprovação básica sempre existe e é o ponto de entrada das aprovações }
Result := TWAprovacaoBasica.Create;
lUltSucessor := Result;
if AUsuario.TipoCargo >= tcGerente then begin
lAux := TWAprovacaoGerente.Create;
lUltSucessor.SetSucessor (lAux);
lUltSucessor := lAux;
end;
{ Cria sucessivamente a hierarquia de aprovações ... }
if AUsuario.TipoCargo >= tcDiretor then begin
lAux := TWAprovacaoDiretor.Create;
lUltSucessor.SetSucessor (lAux);
lUltSucessor := lAux;
end;
{ ... }
end;
A função que obtem a instância da hierarquia de aprovações pode, então, ser utilizada dentro da classe do tipo Client para realizar as operações necessárias. No diagrama do início do post, o tipo Client é encarnado pela classe TWBusinessObj. Se for preciso modificar as regras de negócio ou os relacionamentos existentes na cadeia, a classe Client fará uso das novas regras sem que seja necessário modificá-la - graças ao grau baixo de acoplamento existente.
As regras apresentadas neste exemplo são deliberadamente simples para reforçar o conceito por trás do Design Pattern. Obviamente, as regras de aprovação podem ser muita mais complexas, envolvendo outros elementos e cenários existentes numa aplicação real, assim como a montagem da hierarquia de aprovação pode gerar uma cadeia muito mais extensa.
Handler é a classe que descreve a interface que é disponibilizada para aqueles que pretendem submeter uma requisição. Ou seja, é uma classe abstrata que apenas oferece os pontos de entrada para as requisições que poderão ser feitas; as transações que forem utilizá-la não saberão de antemão quais nem quantos são os níveis hierárquicos existentes, tampouco as regras aplicadas. No diagrama acima, este é o papel da classe TWAprovacao.