Dispatch de métodos e hierarquia de classes em R
O sistema de classes do R é uma daquelas coisas que todo mundo usa sem realmente entender como funciona por baixo dos panos. Quando você chama um print() ou um summary() em um objeto, o R não sabe magicamente o que fazer. Ele percorre uma lista de possibilidades baseada na classe do seu objeto e nos argumentos que você passou. Isso é o que chamamos de dispatch de métodos. Existem basicamente dois sistemas aqui. O S3, que é o mais antigo e o mais usado, e o S4, que veio depois e é mais rígido. O S3 funciona com funções genéricas que verificam a classe do primeiro argumento e procuram uma função chamada no formato generica.classe. Se não encontrar, ele sobe na hierarquia de classes e tenta novamente. O S4 é mais formal — você define classes com slots, cria generics de verdade, e o sistema de dispatch olha para todos os argumentos, não só o primeiro.
O que é ordens e classe no contexto do R
A "ordem" se refere à sequência em que o R procura métodos durante o dispatch. No S3, essa ordem depende da herança de classes. Se um objeto tem classe c("meu_df", "data.frame", "matrix"), o R vai tentar meu_metodo.meu_df, depois meu_metodo.data.frame, e por fim meu_metodo.matrix. Se nenhum desses existir, ele cai no método padrão meu_metodo.default, se tiver sido definido. Isso parece simples até você se deparar com um caso real. Eu estava trabalhando em um projeto onde precisávamos sobrescrever o comportamento de uma função predict() para um modelo personalizado. Nosso objeto tinha três classes na hierarquia, e o dispatch estava indo para o método errado porque alguém havia adicionado uma classe intermediária que eu não esperava. A solução foi usar class(objeto) - c("nova_classe", "data.frame") para garantir que a ordem de busca estivesse correta antes de chamar o predict. Perdi duas horas descobrindo isso.
O problema é que a ordem das classes no vetor class() é absolutamente crítica. Se você inverter dois elementos, o método que vai disparar muda completamente. E isso não é algo que o R te avisa — ele simplesmente escolhe o primeiro método que encontra e segue em frente.
Como funciona na prática
Vamos ver um exemplo concreto de como o dispatch S3 opera. Quando você escreve uma função genérica, precisa usar UseMethod() dentro dela. Sem isso, o R trata tudo como uma função normal e ignora a hierarquia de classes. Uma coisa que muitos programadores que vêm de linguagens como Python ou Java não percebem é que o S3 não tem validação de argumentos. Você pode passar qualquer coisa para qualquer método e o R vai tentar executar. Se a classe não tiver o método correspondente, você recebe um erro apenas no momento da execução, não na definição. Isso significa que bugs de dispatch podem passar despercebidos por semanas até alguém chamar a função com um tipo de dado inesperado.
👉 Clique no botão abaixo para saber mais sobre o assunto!
No S4, a situação é diferente. O sistema S4 exige que você declare as signatures dos métodos usando setMethod(), e o dispatch considera a classe de todos os argumentos envolvidos. Isso resolve o problema de múltiplos dispatch, mas introduz outra complexidade: a coerção de classes. O R pode tentar converter automaticamente um objeto de uma classe para outra se encontrar uma definição de coerce entre elas, e isso pode produzir resultados surpreendentes se você não tiver controle sobre essas regras. Outro detalhe importante que quase ninguém menciona: o ordenamento dos argumentos na chamada da função genérica importa no S4 mas não no S3. No S3, apenas o primeiro argumento é usado para determinar a classe do método. Isso é uma limitação conhecida e documentada, mas continua sendo a fonte de muitos erros em código legado.
Quando usar cada sistema
O S3 é suficiente para a grande maioria das situações. Se você está escrevendo um pacote para uso interno ou mesmo para compartilhar na CRAN, o S3 cobre 95% dos casos de uso. A única vez que o S4 faz sentido é quando você precisa de múltiplo dispatch genuíno — quando o método a ser escolhido depende de duas ou mais classes de argumentos, não apenas da primeira. Isso é raro em práticas comuns de análise de dados. O S4 também é mais lento. Em benchmarks que fiz, funções S4 levam cerca de 2 a 3 vezes mais tempo para resolver o dispatch do que funções S3 equivalentes. Para operações que são chamadas milhões de vezes dentro de um loop, essa diferença se acumula. Se performance é crítica, considere usar R6 classes ou simplesmente funções normais com verificação explícita de tipos.
Há também o sistema RC (Reference Classes), que é baseado em S4 mas tem semântica de referência em vez de valor. Ele é útil quando você precisa de mutabilidade e encapsulamento estilo orientação a objetos, mas traz sua própria complexidade e incompatibilidades com ferramentas baseadas em S3 como muitas funções do tidyverse.
Pitfalls comuns
O erro mais frequente que vejo em código alheio é a falta de um método .default definido. Quando o dispatch não encontra nenhum método correspondente, o R retorna um erro. Sem um default, você não tem fallback. Sempre defina um método padrão como segurança, mesmo que ele apenas chame a implementação original ou lance um erro com uma mensagem clara. Outro problema é a ordem incorreta no vetor de classes. Ao criar um novo objeto, o R preserva a ordem das classes conforme você as atribui, mas funções como as() podem reordenar classes de forma diferente do esperado. Se você precisa de controle fino sobre a hierarquia, seja explícito: defina a ordem das classes manualmente em vez de depender do comportamento padrão do R.
Finalmente, o namespace management do R pode causar problemas silenciosos. Se você carrega dois pacotes que definem métodos para a mesma classe genérica, o método que prevalece depende da ordem de carregamento. Um pacote carregado por último sobrescreve métodos do pacote carregado primeiro. Isso é particularmente traiçoeiro porque não gera warnings — o R simplesmente escolhe e segue. Verifique sempre methods(generic) para ver quais métodos estão realmente registrados antes de confiar que seu código vai disparar o método certo. Se você está começando agora e quer apenas implementar uma interface simples, evite S4 e RC. Fique com S3, defina generics claras, crie métodos por classe, e adicione um default. Essa é a abordagem que vai funcionar na maioria dos casos e vai te dar menos dor de cabeça do que qualquer alternativa mais sofisticada.
