Boas Práticas de Structs & Enums
Projete tipos de dados para que invariantes vivam em um só lugar e o compilador ajude a aplicá-los.
Como Usar Esta Lista
- Aplique ao projetar novos tipos de domínio antes de escrever a lógica.
- Revise durante Pull Requests que adicionam flags
boolou "sopa" deOption. - Use em conjunto com Modelagem de Domínio com Tipos.
A - Design de Structs
- Prefira structs pequenas e focadas em vez de "god objects". Divida quando os campos se agruparem em ciclos de vida distintos.
- Torne os campos privados; exponha construtores e acessadores. Preserve invariantes.
- Use newtypes para IDs e unidades.
struct UserId(u64)previne trocas de argumentos. - Derive
Debug,Clone,Eqquando a semântica corresponder. Documente quando não derivar. - Evite campos
Vecpúblicos, a menos que sejam verdadeiramente irrestritos. Exponha iteradores ou métodos.
B - Design de Enums
- Substitua pares de booleanos por enums quando os estados se multiplicarem.
enum Phaseé melhor queis_started+is_done. - Coloque dados apenas em variantes que precisam deles.
ReadyvsRunning { token }. - Use
#[non_exhaustive]em enums públicos extensíveis. Evolução compatível com versões futuras. - Transicione via métodos que consomem
self. Transições ilegais se tornam erros de tipo ouResult. - Use
Boxem cargas úteis grandes de variantes. Mantenha o tamanho do enum razoável.
C - Pattern Matching
- Mantenha os braços do
matchpequenos; extraia helpers. Funções de transição legíveis. - Prefira
if letpara fluxos de padrão único. Reduza o ruído em comparação commatchde um braço. - Use
let elsepara padrões necessários. Retorno antecipado em formato inesperado. - Evite
unwrapem enums de domínio em código de biblioteca. RetorneResultcom contexto. - Teste cada variante em caminhos críticos. A adição de variantes deve falhar nos testes até ser atualizada.
D - Serialização e APIs
- Separe DTOs de rede dos tipos de domínio quando as formas diferirem. Valide na fronteira.
- Use atributos
serdeem enums para JSON com tag.#[serde(tag = "type")]etc. - Documente a semântica das variantes em rustdoc. Consumidores também fazem correspondência externamente.
- Versionar discriminantes de enum persistidos. Plano de migração ao reordenar variantes.
- Não exponha enums internos em APIs públicas sem uma história de estabilidade. Implicações de Semver.
FAQs
Struct vs enum para campos opcionais?
Muitas combinações opcionais sugerem variantes de enum ou sub-structs.Quando usar struct tupla?
Newtypes de campo único e wrappers finos.Padrão Builder?
Muitos campos opcionais na construção - struct builder separada.Enums achatados em DB?
Armazene a tag + payload JSON; valide na leitura.Muitas variantes?
Divida em sub-enums ou objetos de trait na fronteira.Clone vs referência em variantes?
Dados próprios em variantes; empreste em métodos com lifetimes se for zero-copy.Variante padrão?
`#[default]` no enum para `Default` derive.Testes exaustivos?
`match` no teste sobre todas as variantes com verificação em tempo de compilação.Nós de grafo?
Índices em `Vec` em vez de `Rc<RefCell<Node>>` até que sejam necessários.Próximos passos?
Traits para comportamento nesses tipos.Relacionados
- Noções Básicas de Structs
- Enums para Máquinas de Estado
- Noções Básicas de Traits
- Boas Práticas de Tratamento de Erros
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+.