PADROES GRASP

Prévia do material em texto

Padrões para Atribuições de Responsabilidades
Motivação 
Más escolhas de atribuição de responsabilidades geram sistemas e componentes frágeis e de difícil manutenção, extensão e reutilização.
Quando utilizar?
Padrões são utilizados durante a criação dos diagramas de interação
O que são Padrões?
Princípios, estilos e regras de programação, codificados em um formato estruturado, descrevendo problema/solução 
Um Padrão é um par nomeado problema/solução, que pode ser utilizado em novos contextos, com conselhos sobre como utilizá-lo em novas situações.
O que não são Padrões?
Novos princípios da Engenharia de Software. Ao contrário, padrões tentam codificar o conhecimento, idiomas e princípios existentes
Responsabilidades e Métodos
Responsabilidade - contrato ou obrigação de uma classe
Métodos - utilizados para implementar Responsabilidades
Tipos de Responsabilidades:
Fazer – ele próprio; iniciar ações em outros objetos; controlar atividades em outros objetos
Conhecer – dados privados; objetos relacionados; coisas que pode calcular e derivar. São dedutíveis do modelo Conceitual
O que são os Padrões GRASP ?
Princípios fundamentais de atribuição de responsabilidades a objetos
Cinco Padrões que abordam questões mais comuns:
Expert (Especialista)
Creator (Criador)
High Cohesion (Coesão Alta)
Controller (Controlador)
Low Coupling (Acoplamento Fraco)
�
Padrão Expert – Especialista
Solução: atribui a responsabilidade ao especialista da informação
Exemplo: Aplicação de Ponto de Venda – Qual a classe que deve conhecer o total de venda?
É necessário conhecer todas as instâncias de ítem de venda e a soma de seus subtotais
A Classe VENDA é a especialista para o Total da Venda
Que informações são necessárias para determinar o total de um ítem de venda? 
ItemVenda.Quantidade
Produto.Preço
ÍtemVenda conhece sua quantidade e seus Produtos associados
Ítem Venda é o especialista para determinar o subtotal 
ÍtemVenda deve conhecer o preço do Produto. 
Produto é o especialista informar o seu preço
Conclusão
a satisfação de uma responsabilidade requer informações espalhadas por diferentes classes. 
desta forma existem vários especialistas parciais que colaboram com a tarefa
Favorece ao acoplamento fraco uma vez que os objetos usam suas próprias informações para executarem as tarefas
As classes ficam “leves” gerando alta coesão 
Padrão Creator – Criador
Solução: atribua à classe B a responsabilidade de criar instâncias da classe A se:
B agrega objetos de A
B contém objetos de A
B registra instâncias de objetos A
B usa de maneira muito próxima objetos A
B tem os dados de inicialização que serão passados para o objeto A, quando de sua criação ( B é um especialista com a relação a criação de A) 
Exemplo: Aplicação de Ponto de Venda – Quem deveria ser responsável pela criação de um ItemVenda referente a uma Venda?
A Classe VENDA é a responsável por criar os ItemVenda
Conclusão
O objetivo do padrão é encontrar um Criador que necessita ser conectado ao objeto criado
O criador pode ser encontrado procurando a classe que tem os dados de inicialização que serão passados durante a criação
Exemplo: criação de uma instância de Pagamento com o total de Venda – Venda deve ser o criador de Pagamento.
�
Padrão Low Coupling (Acoplamento Fraco)
Solução: atribuir a responsabilidade de maneira que o acoplamento permaneça fraco.
Exemplo: Aplicação de Ponto de Venda – Quem deveria ser o responsável pela criação de uma instância de Pagamento com o total da venda e associá-la a Venda?
A Classe VENDA é a responsável por criar o Pagamento
Conclusão
Corresponde a um padrão de avaliação
Não há uma medida que determine quanto um acoplamento é muito forte
O importante é avaliar o grau atual de acoplamento e julgar se seu aumento trará problemas
Se o acoplamento fraco é aplicado em excesso, leva a um projeto fraco, pois conduz a poucos objetos ativos, se coesão, inchados e complexos, que efetuam todo o trabalho.
acoplamento fraco permite entendimento isolado, maior reutilização
�
Padrão High Cohesion (Coesão Alta)
Solução: atribuir uma responsabilidade de modo que a coesão permaneça alta.
Alta Coesão - Uma classe com responsabilidades altamente relacionadas e que não executa um formidável volume de trabalho.
Baixa Coesão - Uma classe que faz muitas coisas não relacionadas ou executa demasiado trabalho. Gera dificuldades para manter, reutilizar, compreender, e constantemente afetadas por mudanças.
Conclusão
Corresponde a um padrão de avaliação
Como regra uma classe com coesão alta tem um número relativamente pequeno de métodos, com funcionalidades relacionadas e não executa muito trabalho.
�
Controller – Controlador
Solução: atribui a responsabilidade do tratamento de uma mensagem de um evento do sistema a uma classe que representa uma das escolhas:
controlador fachada - representa o sistema todo ou todo o negócio ou organização. Adequado quando existem poucos eventos do sistema
controlador de papel - representa algo no mundo real que é ativo ( por exemplo o papel de uma pessoa) e que pode estar envolvido na tarefa. 
controlador de caso de uso - representa um tratador artificial de todos os eventos de sistema de um caso de uso. Adequado quando existem muitos eventos do sistema em diferentes processos.
Observações: 
Deve ser usada a mesma classe controladora para todos os eventos do sistema de um mesmo caso de uso.
	Classes como interfaces externas ( janelas, applet, etc.) não devem executar eventos do sistema. Apenas são responsáveis por receberem estes eventos e delegarem a um controlador
	Operações do sistema que refletem processos de negócio devem ser tratadas na camada de objetos de domínio.
O que é um Controlador?
É um objeto de interface	, responsável por tratar um evento do sistema. Um controlador define um método para a operação do sistema.