GRASP: Information Expert, Creator, Controller, Low Coupling, High Cohesion etc.

A ideia que organiza o assunto

Projetar orientado a objetos, na prática, é decidir onde cada responsabilidade vai morar. Quem calcula o total do pedido: o pedido, o item ou uma classe de serviço? Quem cria a instância do item: a venda ou a interface? Errar essas decisões não quebra o programa — produz um sistema que funciona hoje e que ninguém consegue mudar depois, porque a informação está em um lugar e a lógica que a usa está em outro.

O GRASP (general responsibility assignment software patterns) é o conjunto de padrões que responde a essa pergunta. Não são estruturas de classes como os padrões GoF: são critérios de atribuição de responsabilidade, formulados como problema e solução, mais princípios de avaliação do resultado. Cada um responde a uma pergunta distinta, e é confundir essas perguntas que derruba o candidato:

• quem faz, porque tem os dados? → Information Expert (Especialista da Informação).
• quem instancia? → Creator (Criador).
• quem recebe o evento vindo da interface? → Controller (Controlador).
• o resultado ficou bom? → baixo acoplamento e alta coesão, que não dizem a quem dar a responsabilidade, mas medem a escolha feita.

O método de prova é o mesmo do resto do assunto de padrões: leia o critério que o item descreve, decida qual pergunta ele responde, e só então confira o nome assinado.

Como funciona

Information Expert. Atribua a responsabilidade à classe que tem a informação necessária para cumpri-la. Se o cálculo depende dos itens da venda, quem calcula é a venda, que os conhece. O efeito colateral é bom e é o motivo do padrão: a lógica fica junto dos dados, o que reduz o vaivém de dados entre objetos, mantém o encapsulamento e produz classes coesas. Note que Expert atribui a responsabilidade a quem detém a informação — não a abstrações, não à classe mais “importante”, e não à interface.

Creator. Atribua à classe B a responsabilidade de criar instâncias de A se B agrega A, contém A, registra A, usa A de perto ou tem os dados de inicialização de A. O caso típico é a venda que criar os seus itens de venda: quem já vai guardar o objeto criado é quem deve criá-lo, porque assim não se cria dependência nova nenhuma no sistema.

Controller. Atribua a um objeto que não seja de interface gráfica a responsabilidade de receber e coordenar os eventos do sistema. Ele é a porta de entrada da camada de domínio: a interface captura o clique e repassa ao controlador, que delega o trabalho aos objetos que sabem fazê-lo. O ganho é separar o controle da lógica da apresentação, o que permite trocar a interface ou reutilizar a mesma lógica em outra, e é por isso que o controlador não deve concentrar trabalho — um controlador inchado é sintoma de baixa coesão.

Baixo acoplamento. Acoplamento mede quão fortemente uma classe está ligada a outras — quantas ela conhece, chama, herda ou depende. Acoplamento alto propaga mudança: mexer em uma classe obriga a mexer nas que dependem dela, e dificulta entender ou reutilizar qualquer uma isoladamente. O padrão pede que se avalie cada alternativa de atribuição pelo acoplamento que ela cria.

Alta coesão. Coesão mede quão relacionadas entre si são as responsabilidades de uma classe. Alta coesão significa poucas responsabilidades, fortemente relacionadas e voltadas a um único propósito — o que torna a classe fácil de entender, de manter e de reutilizar. Uma classe que faz muitas coisas diferentes é de baixa coesão, e o argumento de que isso aumentaria o reúso é exatamente o inverso da verdade.

Os demais. Completam o conjunto o Polymorphism (comportamento que varia por tipo resolve-se por polimorfismo, não por condicional sobre o tipo), a Pure Fabrication (classe artificial, sem correspondência no domínio, criada para preservar coesão e acoplamento), a Indirection (um intermediário desacopla dois objetos) e as Protected Variations (identifique o ponto de variação previsível e proteja-o com uma interface estável, de modo que a mudança de um lado não atinja o outro).

O que decide os itens

Padrão → pergunta que ele responde:

padrão	pergunta	critério
Information Expert	quem faz?	quem tem a informação necessária
Creator	quem instancia?	quem agrega, contém, registra, usa ou tem os dados de A
Controller	quem recebe o evento do sistema?	objeto fora da camada de apresentação
Baixo acoplamento	está bom?	ligações de uma classe com as outras
Alta coesão	está bom?	responsabilidades relacionadas dentro da classe
Polimorfismo	comportamento varia por tipo	distribuir por subtipo, não por condicional
Pure Fabrication	e quando nenhuma classe do domínio serve?	classe artificial que preserva coesão
Indirection	como desacoplar dois objetos?	intermediário entre eles
Protected Variations	como conter o impacto da mudança?	interface estável no ponto de variação

Coesão × acoplamento — 3 dos 10 itens do corpus trazem uma das duas palavras, e os três são Errados:

	mede	alta/alto é
coesão	o quanto as responsabilidades de dentro da classe se relacionam	desejável: poucas responsabilidades, um propósito
acoplamento	o quanto a classe depende de fora, de outras classes	indesejável: mudança se propaga

Regra de leitura: se a frase fala de ligação entre classes, é acoplamento, ainda que escreva coesão; se fala do conteúdo de uma classe, é coesão.

Expert × Creator × Controller:

×	quem é quem
Expert × Creator	criar instância é Creator; executar com os dados que se tem é Expert
Creator × Controller	quem agrega e usa objetos da outra classe deve criá-los (Creator); quem trata evento do sistema é Controller
Controller × interface gráfica	o controlador não é a janela, a tela nem o widget: é objeto de domínio ou de sistema
Baixo acoplamento × Protected Variations	preservar interfaces já existentes diante da mudança é Protected Variations

GRASP × GoF. GRASP atribui responsabilidade e avalia o projeto; GoF cataloga soluções estruturais recorrentes. Alguns se tocam — Indirection e Protected Variations aparecem no proxy, no adapter e no observer —, mas o item que pede “padrão GRASP” espera um dos nove nomes acima.

Números que caem

padrões GRASP (Larman, 3ª edição)	9
nomeados nos 10 itens medidos	Expert 3, Creator 3, Controller 3, coesão ou acoplamento 3
condições que indicam o Creator	5: agrega, contém, registra, usa de perto, tem os dados de inicialização
responsabilidades de uma classe de alta coesão	poucas e fortemente relacionadas

Como a CEBRASPE derruba você aqui

Medido sobre os 10 itens do tópico: 4 Certo e 6 Errado. Dez itens não produzem frequência — qualquer percentual aqui seria teatro —, mas duas contagens saem limpas e valem como direção:

• os 3 itens que trazem as palavras coesão ou acoplamento são todos Errados;
• os 3 itens que afirmam algo sobre o Controller são todos Certos.

Isso já corrige o recorte do tópico. O título promete Information Expert, Creator e Controller, e esses três decidem 7 dos 10 itens — mas metade dos itens errados não está entre eles: está em coesão, em acoplamento e nas Protected Variations, que o título não menciona. Quem revisar só o trio de padrões de atribuição chega à prova sem a parte que mais derruba.

Descrição certa, nome errado — 4 dos 6 itens errados, e é o formato dominante. Em nenhum deles a frase é absurda: o que está escrito descreve corretamente outro conceito. “a alta coesão (high cohesion) serve para mensurar quão fortemente uma classe está conectada a outras classes” — medir ligação com outras classes é acoplamento. “Determinar quando deve ser delegada a responsabilidade para outro objeto é responsabilidade do criador (creator)” — o criador responde a quem instancia; quem recebe o evento e distribui o trabalho é o Controller. “Aplicando-se o padrão (…) especialista da informação (…) ficará claramente definida de quem é a responsabilidade pela criação de nova instância” — criação é Creator. E “a arquitetura MVC aplica o princípio do baixo acoplamento (…) quando preserva as interfaces já desenvolvidas” — preservar interface diante da mudança é Protected Variations, e ainda troca quem emite a notificação, que no MVC é o modelo. A defesa é uma ordem de leitura: cada padrão GRASP responde a uma pergunta só; leia o critério, decida que pergunta ele responde e só então confira o nome assinado embaixo. Palavras que já entregam a pergunta: criação, instância e nova instância apontam para o Creator; conectada a outras, depende de e conhece apontam para acoplamento; preservar a interface aponta para Protected Variations.

O critério que define o padrão, negado — 2 dos 6. Aqui não há padrão vizinho: o item desmonta a definição por dentro. “uma classe [com] várias e diferentes responsabilidades, para que se aumente sua reutilização (…) alta coesão” — alta coesão é o contrário, poucas responsabilidades fortemente relacionadas; e note que o reúso é alegado como benefício dos dois lados, de modo que julgar pelo benefício não decide nada. Julgue pela quantidade e pela afinidade das responsabilidades descritas. E “atribuir responsabilidades para abstrações, e não para objetos, faz parte do padrão Expert” — o critério do Expert é um só, a posse da informação; trabalhar sobre abstração estável é Protected Variations e polimorfismo. Quando o item negar o critério que define o padrão, o verdadeiro é o contrário do que está escrito.

O que os 4 Certos ensinam. Todos são formulação literal do padrão, sem rodeio: a responsabilidade vai para a classe que possui a informação necessária (Expert); o Controller existe para separar o controle da interface do restante do sistema e para receber os eventos do sistema; quem agrega e usa objetos da outra classe deve criá-los, e por isso o Creator é mais indicado que o Controller nessa situação. Item de GRASP que enuncia o padrão do jeito do livro tende a ser Certo; o erro mora no nome trocado, não na definição estranha.

Erros clássicos

Achar que coesão e acoplamento são o mesmo eixo. São duas medidas independentes e ambas olham para lados diferentes: coesão, para dentro da classe; acoplamento, para as ligações dela com o resto. O projeto bom quer alta coesão e baixo acoplamento ao mesmo tempo.

Confundir Controller com a tela. O controlador existe justamente para que a lógica não fique na interface gráfica. Se o objeto citado é janela, formulário ou componente visual, não é o Controller do GRASP.

Deixar o Controller fazer o trabalho. A função dele é receber o evento e delegar. Controlador que executa as regras vira classe de baixa coesão e concentra acoplamento com meio sistema.

Supor que Expert é sempre a melhor escolha. Aplicar Expert cegamente pode colocar responsabilidade de persistência ou de interface dentro de uma classe de domínio, ferindo a coesão. É aí que entram Pure Fabrication e Indirection.

Tratar GRASP como catálogo de estruturas. GRASP não desenha classes: ele justifica por que a responsabilidade foi para aquela classe. É um vocabulário de argumentação de projeto.