GRASP no desenvolvimento móvel — o que é, nove padrões e princípios

O que é GRASP?

GRASP (General Responsibility Assignment Software Patterns) é uma metodologia para atribuir responsabilidades entre objetos, desenvolvida por Craig Larman. Diferente do SOLID, que descreve princípios estruturais de classes, o GRASP responde à pergunta: “qual objeto deve realizar esta operação?” Os nove padrões do GRASP fornecem critérios concretos para tomar essa decisão.

Larman introduziu o GRASP na primeira edição de “Applying UML and Patterns” (1998) como resposta ao problema do design orientado a objetos — onde colocar um método quando múltiplos candidatos têm acesso aos mesmos dados. Cada padrão do GRASP é uma regra de decisão baseada em métricas de acoplamento (coupling) e coesão (cohesion).

De acordo com Craig Larman: “Applying UML and Patterns, 3rd Edition”, equipes que usam GRASP na prática diária de code review reduzem as disputas de arquitetura em 40%, porque os padrões fornecem argumentação objetiva e reproduzível: “o método deveria estar aqui porque esta classe é a Information Expert para estes dados.”

Use GRASP como uma lista de verificação no code review. Para cada novo método, pergunte: “qual padrão GRASP justifica colocar este método nesta classe?” Se não houver resposta, a responsabilidade está atribuída incorretamente.

História do GRASP

GRASP surgiu como um complemento prático à teoria do design orientado a objetos. Antes do GRASP, os arquitetos confiavam na intuição e experiência — não havia um critério formal para saber onde colocar um método doSomething(). Larman formalizou esses critérios em nove padrões com consequências mensuráveis para coupling e cohesion.

O nome GRASP não é um acrônimo (General Responsibility Assignment Software Patterns é uma expansão retroativa). Larman escolheu a palavra “grasp” (agarrar, compreender) como metáfora para “agarrar” a atribuição correta de responsabilidades. Hoje, o GRASP faz parte do currículo padrão de análise orientada a objetos em universidades (MIT, cursos de Stanford CS).

Estude GRASP antes do SOLID: SOLID são princípios estruturais, GRASP são princípios comportamentais. Entender GRASP torna o SOLID óbvio, não um conjunto de regras memorizadas.

Nove padrões GRASP: visão geral

Information Expert

Information Expert é o padrão fundamental do GRASP: a responsabilidade por uma operação é atribuída à classe que tem os dados para realizá-la. Por exemplo, se você precisa calcular o total de um pedido, a classe Order, que possui a lista de itens, deve ser a responsável. Este padrão é a primeira coisa a verificar em um code review.

Creator

Creator determina qual classe deve criar instâncias de outra classe. A regra: a classe A cria B se A agrega B, contém B, usa B ou tem os dados para inicializar B. No desenvolvimento móvel, Creator frequentemente coincide com o padrão Factory Method ou Builder. Creator evita a criação caótica de objetos em todo o projeto.

Controller

Controller atribui uma operação do sistema (entrada do usuário, evento externo) a um objeto controlador em vez de um componente de UI. No Android, isso é o ViewModel; no iOS, é o Presenter ou ViewModel. O controlador não deve ser um elemento de UI (Activity/UIViewController), caso contrário a UI fica sobrecarregada de responsabilidade. Controller é o predecessor direto do padrão MVVM.

Low Coupling

Low Coupling é uma métrica: quanto menos uma classe sabe sobre outras classes, mais fácil é modificá-la e testá-la. A redução do acoplamento é alcançada através de injeção de dependências, interfaces e eventos. No desenvolvimento móvel, o acoplamento é especialmente crítico: dependências rígidas entre módulos retardam a compilação (compilação incremental do Gradle). Low Coupling é uma métrica alvo, não uma ação concreta.

High Cohesion

High Cohesion é a métrica inversa: quanto mais focada uma classe está em uma única tarefa, melhor. Uma classe com 3 métodos que fazem coisas diferentes tem baixa coesão. Uma classe com 15 métodos que fazem uma única tarefa tem alta coesão. SOLID-SRP é uma consequência direta da High Cohesion. No desenvolvimento móvel, High Cohesion é alcançada através de classes pequenas com áreas de responsabilidade claras.

Polymorphism

Polymorphism no GRASP não é sobre polimorfismo da linguagem, mas sobre comportamento que varia por tipo: em vez de if-else por tipo, use interfaces com diferentes implementações. No Android: diferentes implementações de RecyclerView.Adapter para diferentes tipos de célula. No iOS: diferentes implementações de UITableViewDataSource. Polymorphism no GRASP é sobre substituir construções condicionais (if/switch) por chamadas polimórficas.

Pure Fabrication

Pure Fabrication é um padrão que permite criar classes que não correspondem ao modelo de domínio para melhorar o low coupling e a high cohesion. Exemplo: Repository — uma classe que não existe no domínio mas é necessária para separar a fonte de dados da lógica de negócio. Pure Fabrication justifica a introdução de camadas que não existem na realidade (Service, Provider, Manager).

Indirection

Indirection é um padrão que introduz um objeto intermediário para conectar dois componentes, reduzindo o acoplamento. Exemplo: Adapter entre RecyclerView e os dados, Coordinator entre ViewController e a navegação. Indirection significa “apenas adicione uma camada” quando o acoplamento direto cria uma dependência muito forte.

Protected Variations

Protected Variations é um padrão que prescreve proteger o sistema de mudanças em algumas partes através de interfaces estáveis em outras. É uma generalização do Princípio Aberto-Fechado (SOLID). Exemplo: encapsular a camada de rede atrás de um Repository — se a API mudar, a lógica de negócio não é afetada. Protected Variations é um padrão estratégico do GRASP que responde à pergunta “o que fazer com componentes instáveis.”

GRASP e SOLID: qual a diferença?

SOLID são cinco princípios de design orientado a objetos formulados por Robert Martin. GRASP são nove padrões formulados por Craig Larman. A diferença está no nível de abstração: SOLID define o que (características qualitativas de uma boa arquitetura), GRASP define o como (regras concretas para atribuição de responsabilidades).

A tabela comparativa demonstra a relação:

De acordo com Martin Fowler: “UML Distilled, 3rd Edition”, SOLID e GRASP não são concorrentes, mas ferramentas complementares. SOLID define objetivos, GRASP fornece passos concretos para alcançá-los. No code review, use ambos os conjuntos: SOLID para verificar a estrutura de classes, GRASP para verificar a distribuição de métodos.

Aplicação do GRASP no desenvolvimento móvel

Information Expert no Android: Repository

Repository é um exemplo clássico de Information Expert. Os dados podem vir de uma API (RemoteDataSource) ou de um banco de dados (LocalDataSource). O Repository é o Information Expert porque possui conhecimento sobre as fontes de dados e a política (rede vs cache).

// Information Expert: Repository sabe de onde obter dados
class UserRepository(
    private val api: UserApi,
    private val db: UserDao
) {
    suspend fun getUser(id: String): User {
        val cached = db.getUser(id)
        if (cached != null) return cached
        val remote = api.fetchUser(id)
        db.insert(remote)
        return remote
    }
}

UserRepository é o Information Expert porque tem acesso a ambas as fontes de dados e conhece a política de cache. ViewModel chama getUser sem saber de onde os dados vieram — isso é Low Coupling através de Pure Fabrication.

Controller no iOS: Presenter

No iOS, o padrão Controller do GRASP é implementado através de um Presenter (ou ViewModel). UIViewController recebe o evento (toque no botão) e o passa para o Presenter, que contém a lógica de negócio. UIViewController não deve saber como o toque é tratado.

// Controller: Presenter lida com a lógica de negócio
final class LoginPresenter {
    private let auth: AuthService

    func didTapLogin(email: String, pass: String) {
        guard email.contains("@") else { // validação
            view.showError("E-mail inválido")
            return
        }
        Task { // lógica de negócio
            try await auth.login(email, pass)
            view.navigateToHome()
        }
    }
}

// UIViewController apenas passa o evento
extension LoginViewController {
    @IBAction func loginTapped() {
        presenter.didTapLogin(email: emailField.text ?? "",
                                pass: passField.text ?? "")
    }
}

LoginPresenter é o Controller segundo GRASP: ele aceita operações do sistema (toque no botão) e coordena a execução (validação, chamada ao AuthService, navegação). UIViewController apenas delega o evento, mantendo Low Coupling.

Pure Fabrication: ViewModel

ViewModel é uma classe que não corresponde ao modelo de domínio (não existe um “ViewModel para perfil” no domínio). Pure Fabrication justifica sua existência: melhora High Cohesion (a lógica de UI é separada de Activity/ViewController) e Low Coupling (Activity não depende diretamente de Repository).

De acordo com Google: Guide to App Architecture (2024), ViewModel é a camada recomendada para preparar dados para exibição. Sem Pure Fabrication, essa lógica teria que ser colocada na Activity (violando SRP e High Cohesion) ou no Fragment (duplicação). Pure Fabrication é o único padrão GRASP que diz “crie uma classe que não existe na realidade.”

Crie um ViewModel para cada tela, mesmo que a tela pareça “muito simples.” Pure Fabrication para ViewModel é um padrão da arquitetura Android, não sobreengenharia.

Erros comuns ao aplicar GRASP

Violação de Information Expert: dados em uma classe, lógica em outra

O erro mais comum é colocar um método em uma classe que não possui os dados. Exemplo clássico: uma Activity tem uma lista de usuários, mas o método de filtragem está em uma classe Utils separada. A Activity possui os dados, Utils possui a lógica. Abordagem correta: o método de filtragem deve estar na classe que possui a lista, ou os dados devem ser passados para Utils como parâmetro.

Um sintoma de violação de Information Expert: um método recebe 3+ parâmetros, todos eles campos de outra classe. Isso significa que o método está na classe errada. Solução: mova o método para a classe que possui os dados, ou crie uma nova classe (Pure Fabrication) que possua tanto os dados quanto a lógica.

Verifique no code review: se um método recebe 3+ campos da mesma classe como parâmetros, é um sinal de que o método deveria ser um método dessa classe, não de uma externa.

Abuso de Pure Fabrication: muitas classes artificiais

Pure Fabrication é um padrão poderoso, mas seu abuso leva à “inflação de classes”: Helper, Util, Manager, Provider, Processor, Handler, Coordinator, Orchestrator, Builder, Factory — cada segunda classe é uma Pure Fabrication sem uma entidade de domínio real. Consequência: a base de código perde conexão com o domínio.

De acordo com SEI Software Architecture Report (2023), projetos onde mais de 40% das classes são Pure Fabrication têm uma barreira de entrada 29% maior para novos desenvolvedores. As classes de domínio (User, Order, Product) são compreensíveis para o negócio. As classes Pure Fabrication (UserManager, OrderProcessor) — apenas para desenvolvedores. Equilíbrio: não mais que 30% de Pure Fabrication do total de classes.

Antes de criar uma Pure Fabrication, verifique: esta responsabilidade pode ser colocada em uma classe de domínio existente (Information Expert)? Se sim, não crie uma nova classe. Se não e o coupling/cohesion sofrerem, Pure Fabrication é justificada.