Vous êtes sur la page 1sur 7

Padres para Atribuies de Responsabilidades

Motivao
Ms escolhas de atribuio de responsabilidades geram
sistemas e componentes frgeis e de difcil manuteno,
extenso e reutilizao.
Quando utilizar?
Padres so utilizados durante a criao dos diagramas de
interao
O que so Padres?
Princpios, estilos e regras de programao, codificados
em um formato estruturado, descrevendo
problema/soluo
Um Padro um par nomeado problema/soluo, que
pode ser utilizado em novos contextos, com conselhos
sobre como utiliz-lo em novas situaes.

O que no so Padres?
Novos princpios da Engenharia de Software. Ao contrrio,
padres tentam codificar o conhecimento, idiomas e
princpios existentes
Responsabilidades e Mtodos
Responsabilidade - contrato ou obrigao de uma classe

Mtodos - utilizados para implementar Responsabilidades


Tipos de Responsabilidades:
Fazer ele prprio; iniciar aes em outros objetos;
controlar atividades em outros objetos
Conhecer dados privados; objetos relacionados; coisas
que pode calcular e derivar. So dedutveis do modelo
Conceitual
O que so os Padres GRASP ?
Princpios fundamentais de atribuio de responsabilidades a
objetos
Cinco Padres que abordam questes mais comuns:
Expert (Especialista)
Creator (Criador)
High Cohesion (Coeso Alta)
Controller (Controlador)
Low Coupling (Acoplamento Fraco)

Padro Expert Especialista


Soluo: atribui a responsabilidade ao especialista da
informao
Exemplo: Aplicao de Ponto de Venda Qual a classe
que deve conhecer o total de venda?
necessrio conhecer todas as instncias de tem de
venda e a soma de seus subtotais
A Classe VENDA a especialista para o Total da Venda
Que informaes so necessrias para determinar o
total de um tem de venda?
ItemVenda.Quantidade
Produto.Preo
temVenda conhece sua quantidade e seus Produtos
associados
tem Venda o especialista para determinar o subtotal
temVenda deve conhecer o preo do Produto.
Produto o especialista informar o seu preo
Concluso
a satisfao de uma responsabilidade requer informaes
espalhadas por diferentes classes.
desta forma existem vrios especialistas parciais que
colaboram com a tarefa
Favorece ao acoplamento fraco uma vez que os objetos
usam suas prprias informaes para executarem as
tarefas

As classes ficam leves gerando alta coeso


Padro Creator Criador
Soluo: atribua classe B a responsabilidade de criar
instncias da classe A se:
B agrega objetos de A
B contm objetos de A
B registra instncias de objetos A
B usa de maneira muito prxima objetos A
B tem os dados de inicializao que sero passados para o
objeto A, quando de sua criao ( B um especialista com
a relao a criao de A)
Exemplo: Aplicao de Ponto de Venda Quem deveria
ser responsvel pela criao de um ItemVenda referente a
uma Venda?
A Classe VENDA a responsvel por criar os ItemVenda
Concluso
O objetivo do padro encontrar um Criador que
necessita ser conectado ao objeto criado
O criador pode ser encontrado procurando a classe que
tem os dados de inicializao que sero passados durante a
criao
Exemplo: criao de uma instncia de Pagamento com o
total de Venda Venda deve ser o criador de Pagamento.

Padro Low Coupling (Acoplamento Fraco)


Soluo: atribuir a responsabilidade de maneira que o
acoplamento permanea fraco.
Exemplo: Aplicao de Ponto de Venda Quem deveria
ser o responsvel pela criao de uma instncia de
Pagamento com o total da venda e associ-la a Venda?
A Classe VENDA a responsvel por criar o Pagamento
Concluso
Corresponde a um padro de avaliao
No 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
coeso, inchados e complexos, que efetuam todo o
trabalho.
acoplamento fraco permite entendimento isolado, maior
reutilizao

Padro High Cohesion (Coeso Alta)


Soluo: atribuir uma responsabilidade de modo que a
coeso permanea alta.
Alta Coeso - Uma classe com responsabilidades
altamente relacionadas e que no executa um formidvel
volume de trabalho.
Baixa Coeso - Uma classe que faz muitas coisas no
relacionadas ou executa demasiado trabalho. Gera
dificuldades para manter, reutilizar, compreender, e
constantemente afetadas por mudanas.

Concluso
Corresponde a um padro de avaliao
Como regra uma classe com coeso alta tem um nmero
relativamente pequeno de mtodos, com funcionalidades
relacionadas e no executa muito trabalho.

Controller Controlador
Soluo: 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
negcio ou organizao. 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.
Observaes:
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.)
no devem executar eventos do sistema. Apenas so
responsveis por receberem estes eventos e delegarem a um
controlador
Operaes do sistema que refletem processos de
negcio devem ser tratadas na camada de objetos de
domnio.
O que um Controlador?
um objeto de interface, responsvel por tratar um evento
do sistema. Um controlador define um mtodo para a
operao do sistema.