O documento discute os padrões GRASP (General Responsibility Assignment Software Patterns) que fornecem uma abordagem sistemática para atribuir responsabilidades às classes de um projeto. Os principais padrões discutidos incluem Criador, Especialista, Baixo Acoplamento, Controlador e Coesão Alta.

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
• 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)
A motivação para a separação Modelo-Vista inclui:

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"