Padrão GRASP

Definição:
Responsabilidades
Básicos
Expert
Problema:
Solução
O que o padrão propõe:
Benefícios
Creator
Problema:
Solução:
O que o padrão propõe:
Benefícios:
High Cohesion (Alta Coesão)
Coesão
Problema:
Solução:
O que o padrão propõe:
Benefícios:
Low Coupling (Baixo Acoplamento)
Acoplamento
Problema:
Solução:
O que o padrão propõe:
Benefícios:
Controller
Problema:
Solução:
O que o padrão propõe:
Controlador de Fachada:
Controlador de Caso de Uso:
Benefícios:
Avançados
Polymorphism (Polimorfismo)
Problema:
Solução:
O que o padrão propõe:
Benefícios:

Padrão GRASP 1
 Pure Fabrication
Problema:
Solução:
O que o padrão propõe:
Benefícios:
Indirection
Problema:
O que o padrão propõe:
Benefícios:
Don’t Talk to Stranges
Problema:
Solução:
O que o padrão propõe:
Benefícios:

Definição:
GRASP é um acrônimo para General Responsibility Assignment Software Patterns,
que é um conjunto de padrões de projeto que ajudam a atribuir responsabilidades
claras e específicas para as classes em um sistema orientado a objetos. Esses
padrões ajudam a melhorar a manutenibilidade, flexibilidade e escalabilidade do
sistema.

Responsabilidades
São contratos ou obrigações de um tipo de classe e estão relacionadas às
obrigações de um objeto em termos do seu comportamento. As responsabilidades
podem ser de fazer de um objeto, que incluem iniciativas de ações em outros
objetos, controle e coordenação de atividades em outros objetos, ou de conhecer de
um objeto, que incluem a capacidade de um objeto de conhecer informações sobre
outros objetos.

Básicos

Expert
Problema:

Padrão GRASP 2
 Qual é o princípio mais básico para atribuir responsabilidades em projeto orientado
a objetos?

Solução
Atribuir responsabilidade ao especialista da informação.

Atribuir para a classe que tem a informação necessária para satisfazer a

responsabilidade.

O que o padrão propõe:

Atribuir responsabilidades a classes que possuem a informação necessária para
executar a tarefa.

Esse padrão é baseado na ideia de que uma classe deve ser responsável por
uma tarefa se ela tiver a maior quantidade de informações necessárias para
executá-la.

Esse padrão é amplamente utilizado e é considerado o mais básico dos padrões

GRASP.

:Venda = Conhece o total da venda (RESPONSABILIDADE)

:ItemDeVenda = Conhece o subtotal do item
:EspecificacaoProduto = Conhece o preço do produto

Benefícios

Padrão GRASP 3
 Mantém o encapsulamento: Como as responsabilidades são atribuídas às
classes que possuem a informação necessária, isso ajuda a manter o
encapsulamento, que é um dos princípios fundamentais da programação
orientada a objetos.

Favorece o acoplamento fraco: Como as classes são responsáveis apenas

pelas tarefas que possuem informações, isso ajuda a reduzir o acoplamento
entre as classes, o que torna o sistema mais flexível e fácil de manter.

Favorece a alta coesão: Como as responsabilidades são atribuídas às classes

que possuem a informação necessária, isso ajuda a manter a alta coesão entre
as classes, o que significa que cada classe tem uma única responsabilidade
bem definida.

Creator
Problema:
Quem deve ser responsável por criar uma instância de uma classe?

Solução:
Atribuir a responsabilidade de criação de objetos a uma classe que tenha a
informação necessária para fazê-lo.

O que o padrão propõe:

Atribuir a responsabilidade de criação de objetos a uma classe que tenha a
informação necessária para fazê-lo.

Isso ajuda a manter o encapsulamento e a reduzir o acoplamento entre as

classes.

A Venda pode possuir a responsabilidade de “criar”, instanciar um ItemDeVenda

:Venda contém vários :ItemDeVenda

Padrão GRASP 4
 :Venda possui dados iniciais do pagamento

Benefícios:
Ajuda a manter o encapsulamento.

Reduz o acoplamento entre as classes.

Facilita a manutenção do sistema.

High Cohesion (Alta Coesão)

Coesão
Mede o quanto as responsabilidades de um elemento (Classe e Objeto) são
fortemente relacionadas.

Coesão Alta – Objeto cujas responsabilidades são altamente relacionadas e que

não executa um volume muito grande de trabalho.
Coesão Baixa – Objeto que faz muitas coisas não relacionadas ou executa muitas
tarefas

Problema:
Como garantir que cada classe tenha uma única responsabilidade bem
definida?

Solução:
Atribuir responsabilidades de forma que cada classe tenha uma única
responsabilidade bem definida.

O que o padrão propõe:

Atribuir responsabilidades de forma que cada classe tenha uma única
responsabilidade bem definida.

Isso ajuda a manter o encapsulamento e a reduzir o acoplamento entre as

classes.

É aceitavel nesse exemplo isolado, mas é possivel ver que esse exemplo leva a um
situação onde o TPV vai assumir muitas funções, perdendo sua coesão

Padrão GRASP 5
 Já nesse exemplo cada classe tem sua função (responsabilidade) bem definida

Benefícios:
Ajuda a manter o encapsulamento

Low Coupling (Baixo Acoplamento)

Acoplamento
Dependência entre elementos (Ex: Classes), normalmente resultante de
comunicação necessária para atender uma responsabilidade.

Problema:
Como reduzir a dependência entre as classes?

Solução:
Atribuir responsabilidades de forma que as classes tenham o mínimo possível
de dependência entre si.

O que o padrão propõe:

Atribuir responsabilidades de forma que as classes tenham o mínimo possível
de dependência entre si.

Padrão GRASP 6
 Isso ajuda a manter o encapsulamento e a tornar o sistema mais flexível e fácil
de manter.

Alto acoplamento pois tanto pagamento quanto venda estão ligados ao TPV, ou
seja, não são independentes

Baixo acoplamento, pois só venda depende do TPV e pagamento só depende de

venda

Benefícios:
Ajuda a manter o encapsulamento.

Torna o sistema mais flexível e fácil de manter.

Facilita a reutilização de código.

Controller
Problema:
Como evitar um controlador inchado, com excesso de responsabilidades e falta
de foco?

Padrão GRASP 7
 Solução:
Atribuir responsabilidades de forma que o controlador tenha foco e trate apenas
as responsabilidades necessárias.

O que o padrão propõe:

O padrão GRASP Controller propõe que um controlador deve ser responsável
por receber e tratar as requisições do usuário, delegando as tarefas necessárias
para outras classes.

O controlador deve ter foco e tratar apenas as responsabilidades necessárias,

evitando assim um controlador inchado e com baixa coesão.

Controlador de Fachada:
É um objeto do domínio que representa o ponto principal ou central para todas
as chamadas provenientes da interface com o usuário ou de outros sistemas.

É adequado quando não há uma quantidade muito grande de eventos de

sistema.

Pode ser utilizado para representar todo o sistema, um negócio ou organização,

um dispositivo ou subsistema.

Controlador de Caso de Uso:

Representa um cenário de um caso de uso dentro do qual ocorra um evento.

Padrão GRASP 8
 É responsável por receber e tratar as requisições do usuário para um caso de
uso específico.

Ajuda a manter a coesão e o foco do controlador, evitando que ele se torne

inchado e com baixa coesão.

Benefícios:
Ajuda a manter a coesão e o foco do controlador.

Facilita a manutenção e a evolução do sistema.

Torna o sistema mais flexível e fácil de manter.

Avançados
Polymorphism (Polimorfismo)
Problema:
Como tratar alternativas com base no tipo?

Como criar componentes de software "conectáveis"/"plugáveis"/"substituíveis"?

Solução:

Padrão GRASP 9
 Atribuir responsabilidades aos tipos usando operações polimórficas.

Usar polimorfismo com conceito de interfaces para permitir substituição de

componentes.

O que o padrão propõe:

O padrão GRASP Polymorphism propõe que, quando alternativas ou
comportamentos relacionados variam com o tipo (classe), as responsabilidades
devem ser atribuídas aos tipos usando operações polimórficas.

O uso de polimorfismo com conceito de interfaces permite a substituição de

componentes, tornando o sistema mais flexível e fácil de manter.

Benefícios:
Ajuda a manter a coesão e o foco das classes.

Facilita a manutenção e a evolução do sistema.

Torna o sistema mais flexível e fácil de manter.

Pure Fabrication
Problema:
A quem atribuir responsabilidade quando todas as opções ferem os princípios
da coesão alta e acoplamento fraco?

Solução:

Padrão GRASP 10
 Criar classes artificiais, que não representam o mundo real, para atribuir
responsabilidades e suportar coesão alta, acoplamento fraco e reutilização.

O que o padrão propõe:

O padrão GRASP Pure Fabrication propõe que, quando não há uma classe
natural para atribuir uma responsabilidade, deve-se criar uma classe artificial
para suportar essa responsabilidade.

Essas classes artificiais são soluções de projetos puras, inventadas para

garantir princípios da orientação a objetos.

As classes artificiais ajudam a manter a coesão e o foco das classes, evitando

que elas se tornem inchadas e com baixa coesão.

Benefícios:
Ajuda a manter a coesão e o foco das classes.

Facilita a manutenção e a evolução do sistema.

Torna o sistema mais flexível e fácil de manter.

Indirection
Problema:
Onde atribuir responsabilidade de modo a evitar o acoplamento direto?

Como desacoplar objetos de maneira a possibilitar baixo acoplamento e manter

alto potencial de reuso?

Solução:

Atribuir responsabilidade a um objeto intermediário que faz a mediação

entre outros componentes, evitando o acoplamento direto.

O que o padrão propõe:

O padrão GRASP Indirection propõe que, quando há a necessidade de
desacoplar objetos e evitar o acoplamento direto, deve-se atribuir a
responsabilidade a um objeto intermediário que faz a mediação entre outros
componentes.

Padrão GRASP 11
 Esse objeto intermediário cria uma indireção para outros componentes,
permitindo que eles se comuniquem sem se acoplarem diretamente.

Benefícios:
Ajuda a manter a coesão e o foco das classes.

Facilita a manutenção e a evolução do sistema.

Torna o sistema mais flexível e fácil de manter.

Don’t Talk to Stranges

Problema:
O conhecimento da estrutura interna de relacionamento de uma classe pode
dificultar a manutenção.

Como é possível fortalecer o encapsulamento?

Solução:
Atribuir responsabilidade a um objeto "familiar" de um objeto cliente, para o
"familiar" colaborar com o objeto "estranho" evitando que o objeto cliente fale
com "estranhos" para obter, por exemplo, uma requisição.

O que o padrão propõe:

O padrão GRASP Don't Talk to Strangers propõe que, para fortalecer o
encapsulamento e evitar que um objeto cliente tenha conhecimento da estrutura
interna de relacionamento de uma classe, deve-se atribuir a responsabilidade a
um objeto "familiar" que colabora com o objeto "estranho".

Esse objeto "familiar" é responsável por intermediar a comunicação entre o

objeto cliente e o objeto "estranho", evitando que o objeto cliente tenha acesso
direto à estrutura interna do objeto "estranho".

Padrão GRASP 12
 Benefícios:
Fortalece o encapsulamento e a coesão das classes.

Facilita a manutenção e a evolução do sistema.

Torna o sistema mais flexível e fácil de manter.

Padrão GRASP 13