GRASP Patterns

1
GRASP Patterns

• Projetando Objetos com Responsabilidades

2
GRASP

• General Responsibility Assignment Software
  Patterns
• Os padrões GRASP fornecem uma abordagem
  sistemática para a atribuição de
  responsabilidades às classes do projeto

3
GRASP

• Qual é a conexão entre Responsabilidades, GRASP e
  diagramas UML?
• A ocasião para considerar a atribuição de
  responsabilidades às classes é durante a
  elaboração dos diagramas de seqüência

4
O que são padrões?

• Importante Padrões têm nomes
• A expressão 'um novo padrão' é um paradoxo
• O livro da 'Gang of Four'

5
Os padrões GRASP

• Controller
• Creator
• Information Expert
• Indirection
• Low Coupling
• High Cohesion
• Polymorphism
• Pure Fabrication
• Protected Variations

6
O Criador
7
O Criador (Creator)
Problema Quem deve ser responsável por criar uma
nova instância de uma classe? Solução Atribua à
classe B a responsabilidade de criar uma
instância de A se pelo menos um desses for
verdadeiro (quanto mais melhor)

• B contém ou agrega A
• B registra a existência de A
• B usa A
• B tem os dados necessários para a inicialização
  de A que serão passados ao construtor de A

8
Exemplo Jogo de Banco Imobiliário
Quem deve criar os objetos correspondentes às
peças do tabuleiro?
9
Exemplo Jogo de Banco Imobiliário
visão estática
visão dinâmica
10
Outro exemplo um ponto de venda
Vantagens LRG Contraindicações Criação de
Objetos Complexos
11
O Especialista
12
O padrão Especialista (Information Expert)
Problema Qual é o princípio geral para a
atribuição de responsabilidades aos
objetos? Solução Atribua a responsabilidade ao
especialista a classe que tem as informações
necessárias para assumir a responsabilidade
13
Exemplo O Banco Imobiliário
Quem deve localizar uma posição do tabuleiro dada
a sua identidade?
14
Exemplo O ponto de venda
Quem deve ser responsável por conhecer o total da
venda?
15
Exemplo O ponto de venda
Quem deve ser responsável por conhecer o total da
venda?
16
Exemplo O ponto de venda
Quem deve ser responsável por conhecer os
subtotais?
17
Exemplo O ponto de venda
Quem deve ser responsável por conhecer o preço de
cada item de venda?
18
Exemplo O ponto de venda
19
O padrão Especialista (Information Expert)
Benefícios O encapsulamento da informação é
mantido uma vez que os objetos usam seus próprios
dados para realizar as tarefas. Isto normalmente
leva a um baixo acoplamento entre as classes. O
comportamento do sistema é distribuído entre as
classes que têm as informações, encorajando a
definição de classes mais "leves", mais fáceis de
entender e de manter. Contraindicações Em
algumas situações, a solução sugerida pelo
especialista pode ser indesejada. (Quem deve
persistir uma venda no banco?)
20
Baixo Acoplamento
21
Baixo Acoplamento
Problema Como prover baixa dependência entre
classes, reduzir o impacto de mudanças e obter
alta reutilização? Solução Atribua as
responsabilidades de modo que o acoplamento entre
classes permaneça baixo. Use este princípio para
avaliar alternativas.
22
Exemplo O Banco Imobiliário
Pergunta Por que o Tabuleiro e não um cachorro?
23
Baixo Acoplamento
Ponto Chave O Especialista favorece o Baixo
Acoplamento Retornando à motivação do
especialista ele nos conduz a soluções que
favorecem o baixo acoplamento. O especialista nos
pede que encontremos o objeto que tem a maior
parte da informação necessária para assumir a
responsabilidade (por exemplo, o tabuleiro) Se
pusermos a responsabilidade em algum outro lugar
qualquer (por exemplo, o cachorro) o acoplamento
global será maior porque mais informações terão
de ser compartilhadas entre os objetos.
24
Outro Exemplo O ponto de venda
Suponha que temos de criar um objeto pagamento e
associá-lo à venda. Que classe deve ser
responsável por isso?
1ª alternativa
2ª alternativa
25
Acoplamento entre classes
a) A ClasseA tem um atributo do tipo ClasseB
26
Acoplamento entre classes
b) A ClasseA tem um método que, de alguma forma,
referencia uma instância de ClasseB. Tipicamente,
esta referência se dá através de um parâmetro ou
variável local do tipo ClasseB ou por um objeto
do tipo ClasseB retornado pela chamada de algum
método
27
Acoplamento entre classes
c) A ClasseA é uma subclasse de ClasseB
28
Acoplamento entre classes
d) A ClasseB é uma interface e a ClasseA
implementa esta interface
29
Acoplamento entre classes

• Discussão
• Classes que, por natureza, são genéricas e que
  têm alta probabilidade de reutilização deveriam
  ter acoplamento baixo
• O caso extremo do baixo acoplamento é o não
  acoplamento contraria o princípio da orientação
  a objetos objetos conectados, trocando mensagens
  entre si.
• O acoplamento alto não é o problema em si. O
  problema é o acoplamento a classes que, de alguma
  forma são instáveis sua interface, sua
  implementação ou sua mera presença.

30
O Controlador
31
O Controlador
Problema Que objeto, fora da camada de
apresentação, deve receber e coordenar a
solicitação da execução de uma operação?
32
O princípio da separação Modelo-Vista
O princípio da separação Modelo-Vista pode ser
enunciado em duas partes

• Não conecte diretamente objetos pertencentes à
  interface com o usuário (a vista) com objetos não
  pertencentes à interface com o usuário (IU).
• Não coloque lógica da aplicação (tal como o
  cálculo de impostos) nos métodos dos objetos da
  IU

33
O princípio da separação Modelo-Vista
A motivação para a separação Modelo-Vista inclui

• Suportar a criação de classes de negócio coesas,
  com foco nos processos do domínio ao invés de na
  interface com o usuário.
• Permitir o desenvolvimento separado das camadas
  de apresentação e negócio.
• Minimizar o impacto na camada de negócio das
  alterações nos requisitos da interface com o
  usuário.

34
O princípio da separação Modelo-Vista
A motivação para a separação Modelo-Vista inclui

• Permitir que novas vistas sejam facilmente
  conectadas aos objetos de negócio existentes, sem
  afetar a camada de negócios.
• Permitir a existência de múltiplas vistas
  simultâneas para uma mesma camada de negócios
  (por exemplo, a visualização de dados de vendas
  na forma tabular ou através de um gráfico de
  pizzas)

35
O objeto Controlador
O objeto Controlador responde a uma questão
básica no projeto de sistemas OO Como conectar a
camada de apresentação à camada da lógica do
negócio?
36
O objeto Controlador
O controlador é o primeiro objeto fora da camada
de interface com o usuário a receber ou tratar
uma mensagem para o sistema. Existem duas
alternativas possíveis para o objeto controlador

• Um objeto Controlador para todo o sistema
• Um objeto Controlador por Caso de Uso (ou por
  cenário de Caso de Uso)

37
O objeto Controlador

• Os benefícios do padrão controlador são
• Diminui a sensibilidade da camada de apresentação
  em relação à lógica de domínio
• Oportunidade para controlar o estado do caso de
  uso

38
Exemplo Ponto de Venda
39
Coesão Alta
40
Coesão Alta
Problema Como manter os objetos focados,
compreensíveis, gerenciáveis e, em conseqüência,
com Baixo Acoplamento? Solução Atribua
responsabilidades de modo que a coesão da classe
permaneça alta. Use esse critério para avaliar
alternativas
41
Coesão Alta
42
Coesão
Uma classe com baixa coesão sofre dos seguintes
problemas

• difícil de compreender
• difícil de reutilizar
• difícil de manter
• frágil freqüentemente tem de ser alterada

43
Coesão

• Como um princípio básico, uma classe com alta
  coesão
• tem um número relativamente pequeno de métodos,
• a funcionalidade desses métodos é altamente
  relacionada, e
• não faz trabalho de mais.

44
Polimorfismo
45
Polimorfismo
Problema Como tratar alternativas baseadas no
tipo? Como criar componentes de software
"plugáveis"? Solução Quando alternativas ou
comportamentos relacionados variam com o tipo
(classe), atribua as responsabilidades aos tipos
usando operações polimórficas.
46
Exemplo
47
O Banco Imobiliário
Como projetar para acomodar as diferentes ações
baseadas no tipo da posição do tabuleiro? Um mau
projeto
48
O Banco Imobiliário
O comportamento estático
49
O Banco Imobiliário
O comportamento dinâmico
50
O Banco Imobiliário
O comportamento dinâmico
51
O Banco Imobiliário
O comportamento dinâmico
52
O Banco Imobiliário
O comportamento dinâmico
53
O Banco Imobiliário
O comportamento dinâmico
54
Pure Fabrication (Pura Invenção)
55
Pure Fabrication
Problema Que objeto deve ter a responsabilidade
quando você não quer violar "Alta Coesão" e
"Baixo Acoplamento", mas as soluções oferecidas
pelo "Especialista" não são apropriadas? Solução
Atribua um conjuto coeso de responsabilidades a
uma classe artificial que não representa um
conceito no domínio da aplicação, uma classe
fictícia que possibilite alta coesão, baixo
acoplamento e o reuso.
56
Ponto de Venda Salvar uma Venda no Banco de Dados
O especialista nos diz para atribuir a
responsabilidade à classe Venda, uma vez que ela
conhece os dados da venda. Considere no entanto
as seguintes implicações

• Salvar um objeto no Banco de Dados implica em uma
  série de operações não relacionadas ao conceito
  de venda
• A classe venda tem de ser associada à interface
  do banco de dados relacional (JDBC, por exemplo)
• Várias outras classes no projeto terão de fazer a
  mesma coisa.

57
Pure Fabrication
58
O Banco de Dados
59
Indireção
60
Indireção
Problema Onde colocar uma responsabilidade de
modo a evitar o acoplamento direto entre duas ou
mais classes? Como desacoplar objetos de modo a
possibilitar o baixo acoplamento e manter alta a
possibilidade de reuso? Solução Atribua a
responsabilidade a um objeto intermediário que
faça a mediação entre componentes ou serviços de
modo que eles não sejam diretamente acoplados.
61
Indireção
Exemplo Indireção através de um adaptador
62
Indireção
"A maior parte dos problemas em Ciência da
Computação pode ser resolvida por um nível
adicional de indireção" Velho provérbio com
especial relevância para sistemas orientados a
objetos "A maior parte dos problemas de
desempenho pode ser resolvida removendo-se
algumas camadas de indireção"