|
Usuários |
|
38 Usuários Online
|
|
[Artigos]
[Intermediário] - Chain of Reponsability - Padrões de Projeto no Delphi Parte I |
Publicado por rboaro : Segunda, Setembro 23, 2013 - 09:58 GMT-3 (339 leituras)
 comentar  Enviar para um amigo  Versão para impressão
|
Situações podem ocorrer corriqueiramente em nossos projetos e não damos conta de sua recursividade e para cada “novo”/velho desafio uma solução é lançada. Dando a impressão que sempre se acha uma nova e “melhor” solução, a cada fez que refazermos o problema. Padrões de Projeto visa exatamente isto ,Definir um Padrão de comportamento na arquitetura de problemas velhos e já documentados . Hoje iremos tratar de um Padrão Chain of Responsability definido na categoria Comportamentais, que não é muito divulgado no Delphi, por ser RAD, o Delphi nos facilita o uso de Ifs e Cases na resolução nova de problemas velhos. Vamos propor o processamento de um Documento seguindo algumas regras que geralmente são detectadas na elaboração da UML quando abstraimos para o mundo “programático” problemas do mundo Real. A idéia é termos vários objetos instanciados , com a capacidade de processar um determinado protocolo e iremos definir qual desses objetos irá fazer a solicitação seguindo certas Validações .
Como exemplo desta Abstração podemos ter :
1. O sistema de compras de uma companhia, onde os Compradores podem submeter os pedidos de compra sem necessitar uma aprovação se o pedido tiver certas características (digamos, um limite máximo de valor) mas que, conforme estas características vão variando, o pedido deve ser submetido a aprovação por níveis hierárquicos cada vez mais altos (supervisor, gerente, diretor, presidente).
2.Sistema de Recebimento de uma concessionária , cujo o recebimento de ativos/produtos/serviços segue alguns critérios como o valor (por várias razões entre essas segurança não existe mais a possibilidade de entrar com um pacote de dinheiro debaixo do braço e sair montado num Carro) . Podendo o Pagamento ser feito no Balcão , no Caixa, com o Gerente ou através de uma Conta (Agência Bancaria )
3.Imagine uma máquina de refrigerantes, na qual vai-se adicionando moedas até o valor do refrigerante ser alcançado para a sua aquisição. Como existem infinitos tipos de moedas, além das moedas que já são antigas e não possui mais validade monetária, a máquina de refrigerantes tem que descobrir qual moeda entrou através de possíveis padrões, como por exemplo, a espessura, raio e peso. Então temos várias classes que representam os diversos valores de moedas , (lembramos ainda que podemos ter moedas de um mesmo valor porém com formatos diferentes) .
Nos dois primeiros cenários proprosto , ao primeiro olhar que traçamos á cerca do Problema/solução nos remete a acharmos mais simples e mais conveniente a utilização de ifs que podemos aplicar na condição e dependendo do resultado processar a requisição com o objeto adequado
if Pedido.valor > condicaoA and < condicaoB then
Supervisor.Compra // requisicao sendo processada
else
if Pedido.Valor => CondicaoB and < CondicaoC then
Gerente.Compra // requisicao sendo processada
else
Pedido.Valor => CondicaoC and < CondicaoD
Diretor.Compra // requisicao sendo processada
e ai Segue o Codigo testando para as Demais condições atê
Chagar no Presidente.Compra
Nos segundo cenário , poderemos implementar uma solução semelhante , já o terceiro cenário no caso das moedas implementar esses IFS , (são muitas as condiçoes a serem testadas .”a espessura”, “raio” e “peso”. ) e muitas as classes Moedas que existem e ainda virão a existir . Toda e qualquer moeda nova com outras especificações , mais condiçoes deverão ser testadas , ficando esta solução muito inviável e no bom sentido da POO um “código que Cheira mal” . Atê o momento estamos falando apenas do ponto de vista de Ifs encadeados o que dificulta a leitura e a manutenção dos códigos , estamos fazendo vista grossa a cerca de outros problemas como o auto Acoplamaneto da classe Form com as demais classe (moedas), a alta coesão existentes entre essas classes, e a Responsabilidade do Form , que deveria ser apenas um “Viewn dos Dados” , fica ainda ter que processar informaçoes , sem contar que toda e qualquer alteração que possa existir (Nova Moeda) , teremos que fazer alteraçoes na nossa classe Formulário ( Um classe deve ser aberta para expansão e nunca para Edição ). O que propõem esta série de artigos que será dividia em três partes é tentar resolver este problema de modo elegante , reutilizável , com baixo acoplamento entre as classes de modo Orientado a Objeto. Para isto recorremos ao Padrão Chain of Responsability onde a requisição feita por um objeto Cliente é transmitida ao longo de uma sequência de Classes até que a requisição seja suprida por uma delas , onde essas requisições envolvem alçadas de aprovação.
Queremos de antemão , dizer que o código que será apresentado visa criar um Modelo Genérico que atenda a qualquer Documento e que tenha válidade tanto para o exemplo simplório do Problema (Compra/Recebimento) abrangendo também o cenário das Moedas.
No momento vou ficando por aqui pela sua atenção meu muito Obrigado …
Link Original do Artigo:
http://marcosalles.wordpress.com/2012/02/27/chain-of-responsability-cadeia-de-responsabidades-padrao-de-projeto-no-delphi-design-patterns-parte-i/
|
|
 Comentários | |
| | Comentários pertencem aos seus respectivos autores. Não somos responsáveis pelo seus conteúdos. |
|
|
Edição 112 |
|
|
50 Programas Fontes |
|
|
Produtos |
|
|
