O Sistema de Traits do Rust como Design de Interface

Um trait descreve o que um tipo pode fazer, não o que um tipo é. Display significa "este tipo sabe como se formatar para um usuário"; Iterator significa "este tipo sabe como produzir uma sequência de valores um de cada vez". Qualquer tipo, em qualquer lugar, pode implementar um trait, o que torna os traits mais próximos de um contrato de capacidade do que de uma hierarquia de classes.

Essa distinção molda como o Rust faz a coisa que a maioria das linguagens chama de "interfaces". Em vez de um único mecanismo, o Rust oferece duas maneiras de usar um trait depois que ele existe: genéricos com monomorfização, resolvidos inteiramente em tempo de compilação, e objetos de trait com despacho dinâmico, resolvidos em tempo de execução. Eles se parecem de forma semelhante na página e se comportam de maneira muito diferente por baixo, e a escolha entre eles é uma das decisões de design de API mais importantes em uma base de código Rust.

Esta página é a âncora conceitual para a seção. Noções Básicas de Traits cobre a sintaxe na prática; esta página explica o que um trait fundamentalmente é e como as duas estratégias de despacho realmente funcionam.

Resumo

• Um trait é um contrato de capacidade - um conjunto de métodos que um tipo promete implementar - e o Rust oferece duas maneiras distintas de programar contra esse contrato: genéricos em tempo de compilação ou objetos de trait em tempo de execução.
• Por que Importa: A escolha entre genéricos e objetos de trait altera o perfil de desempenho do seu programa, o tamanho do binário e a flexibilidade da API; escolher o errado para uma determinada situação custa ou sobrecarga de tempo de execução desnecessária ou rigidez de tempo de compilação desnecessária.
• Conceitos Chave: trait, trait bound, monomorfização, despacho estático, objeto de trait, despacho dinâmico.
• Quando Usar Este Modelo: Decidir se um parâmetro de função deve ser T: Trait/impl Trait ou &dyn Trait, projetar APIs do tipo plugin e entender por que alguns traits não podem se tornar objetos de trait.
• Limitações / Compromissos: Genéricos podem inchar o tamanho do binário com código duplicado por tipo concreto; objetos de trait pagam um pequeno custo de indireção em tempo de execução e não podem usar todos os traits (regras de segurança de objeto se aplicam).
• Tópicos Relacionados: genéricos, despacho estático versus dinâmico, objetos de trait, tipos associados.

Fundamentos

Um trait é declarado uma vez e pode ser implementado por qualquer número de tipos não relacionados, em qualquer crate que tenha visibilidade para o trait e para o tipo (sujeito à regra do órfão). Isso é fundamentalmente diferente da herança baseada em classes, onde um método vem de uma única posição fixa em uma hierarquia - um trait é uma promessa que um tipo opta por seguir, não um slot no qual ele herda.

trait Summarize {
    fn summary(&self) -> String;
}

String, uma Article struct personalizada e um tipo Tweet de terceiros poderiam implementar Summarize independentemente, sem que nenhum deles soubesse um do outro ou compartilhasse um ancestral comum. O que os une não é o que eles são, mas que todos eles podem produzir um resumo - uma capacidade, não uma categoria.

Uma vez que um trait existe, você pode escrever código que só precisa saber que um tipo tem essa capacidade, sem se importar com qual tipo concreto ele realmente é. Essa é a essência de um trait bound: fn describe<T: Summarize>(item: T) diz "me dê qualquer coisa que possa se resumir", e o corpo da função pode chamar .summary() sem saber ou se importar se T acaba sendo um Article ou um Tweet.

Mecânicas e Interações

Como esse trait bound é transformado em um programa em execução é onde as duas estratégias de despacho divergem, e a diferença não é cosmética.

Genéricos com um trait bound são resolvidos através de monomorfização: para cada tipo concreto distinto usado com uma função genérica, o compilador gera uma cópia separada e especializada dessa função em tempo de compilação. describe::<Article> e describe::<Tweet> se tornam duas funções completamente diferentes no binário compilado, cada uma com chamadas .summary() resolvidas diretamente para a implementação correta, sem envolvimento de busca em tempo de execução. Isso é despacho estático - o compilador sabe exatamente qual função chamar antes que o programa seja executado.

trait Summarize { fn summary(&self) -> String; }
 
struct Article(String);
impl Summarize for Article {
    fn summary(&self) -> String { format!("Article: {}", self.0) }
}
 
fn describe<T: Summarize>(item: &T) -> String {
    item.summary() // resolvido em tempo de compilação, por T concreto
}

Objetos de trait adotam a abordagem oposta. &dyn Summarize ou Box<dyn Summarize> apagam completamente o tipo concreto, armazenando em vez disso um ponteiro para os dados mais um ponteiro para uma vtable - uma tabela de ponteiros de função para a implementação desse tipo específico do trait. Chamar .summary() através de um objeto de trait significa procurar o ponteiro de função correto na vtable em tempo de execução e, em seguida, pular para ele. Isso é despacho dinâmico, e é o que permite que um único Vec<Box<dyn Summarize>> contenha um Article, um Tweet e qualquer outro implementador de Summarize lado a lado, algo que genéricos sozinhos não podem fazer porque uma função genérica é especializada para um tipo concreto por chamada.

Esse último ponto é a bifurcação prática na estrada: genéricos exigem que o tipo concreto seja conhecível e fixo por local de chamada (ou duplicado por tipo usado), enquanto objetos de trait permitem uma coleção genuinamente heterogênea ou um limite de função onde o tipo concreto do chamador nem mesmo precisa ser nomeado. Nem todo trait pode se tornar um objeto de trait, no entanto - um trait só é object-safe se seus métodos não exigirem o conhecimento do tamanho concreto de Self (sem tipos de retorno Self, sem métodos genéricos no próprio trait), porque uma vtable não tem como representar "um método que retorna qualquer tipo concreto que eu realmente sou".

Considerações Avançadas e Aplicações

Ambas as estratégias de despacho são padrões legítimos para problemas diferentes, e o código Rust de produção usa ambos, muitas vezes no mesmo crate.

O compromisso de tamanho de binário com genéricos é real e às vezes surpreendente: uma biblioteca fortemente genérica usada com dezenas de tipos concretos pode produzir binários notavelmente maiores do que o design equivalente baseado em objetos de trait, porque a monomorfização está literalmente copiando o corpo da função uma vez por tipo. Grandes projetos Rust às vezes introduzem deliberadamente um limite baseado em dyn Trait especificamente para interromper essa duplicação de propagação para fora, aceitando o pequeno custo de despacho em troca de um binário menor e mais previsível.

A diferença de desempenho entre os dois, em termos absolutos, é frequentemente menor do que os desenvolvedores imaginam - uma busca em vtable é um único salto indireto, não um custo significativo na maioria do código de aplicação. A decisão é melhor enquadrada em torno da forma da API do que da velocidade bruta: esse limite precisa aceitar ou armazenar um conjunto genuinamente desconhecido e possivelmente crescente de tipos concretos (use dyn Trait), ou o tipo é sempre resolúvel por local de chamada e sensível ao desempenho (use genéricos)? impl Trait em posição de argumento ou retorno é frequentemente o meio-termo certo quando você deseja a velocidade do despacho estático sem ter que detalhar um parâmetro genérico que o chamador nunca precisa ver.

Tipos associados adicionam um eixo adicional a esse espaço de design: um trait como Iterator usa type Item para permitir que cada implementador fixe um tipo de saída sem transformar esse tipo em um parâmetro genérico do próprio trait, o que mantém os locais de chamada mais simples ao custo de uma implementação por tipo concreto de Item em vez de uma família de implementações parametrizadas sobre ele.

Equívocos Comuns

• "Traits são apenas a versão do Rust para interfaces de Java ou C#." Eles são próximos, mas um trait pode ser implementado para tipos que você não possui (sujeito à regra do órfão) e pode ser usado genericamente sem nunca ser empacotado - interfaces Java/C# são sempre usadas através de uma referência, que é mais próxima do dyn Trait do Rust sozinho.
• "Genéricos e objetos de trait são duas sintaxes para a mesma coisa." Eles compilam para código fundamentalmente diferente - um duplica a função por tipo em tempo de compilação, o outro mantém uma função e procura o comportamento através de uma vtable em tempo de execução - com consequências reais e diferentes de desempenho e flexibilidade.
• "dyn Trait é sempre mais lento e deve ser evitado." A sobrecarga de despacho é uma única chamada indireta, frequentemente insignificante em comparação com o trabalho real sendo feito; objetos de trait são a escolha correta sempre que o conjunto de tipos concretos varia genuinamente em tempo de execução.
• "Qualquer trait pode ser transformado em um objeto de trait com dyn." A segurança de objeto é uma restrição real - traits com métodos genéricos ou métodos que retornam Self não podem se tornar objetos de trait, porque uma vtable não pode representar um método cuja assinatura depende de um tipo concreto apagado.
• "Monomorfização significa que meu código genérico é compilado uma vez e reutilizado para todos os tipos." É o oposto - uma cópia separada é gerada para cada tipo concreto realmente usado, o que torna o despacho estático rápido, mas também é o que aumenta o tamanho do binário.

FAQs

Relacionados

• Noções Básicas de Traits - definindo e implementando traits na prática
• Genéricos - a sintaxe e mecânica de parâmetros genéricos
• Despacho Estático vs Dinâmico - uma comparação mais profunda das duas estratégias
• Objetos de Trait e Despacho Dinâmico - mecânicas de dyn Trait e segurança de objeto em profundidade
• Trait Bounds - restringindo parâmetros genéricos com traits

Versões da Stack: Esta página foi escrita para Rust 1.97.0 (edição 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, e Polars 0.46+.