Ao desenvolver com Swift, chega um momento em que todo mundo fica em dúvida.
“Faço isso com class ou com struct?”
Quando aprendi Swift, eu escolhia entre os dois conforme a vontade. Só estudei a diferença de verdade depois de enfrentar um bug estranho.
Vou direto à conclusão.
Se não houver um motivo especial, escolha primeiro uma struct.
Use uma classe somente quando você realmente precisar de “um estado compartilhado”.
O guia oficial da Apple segue a mesma linha. Hoje vou explicar os motivos passo a passo.
Resumo principal (3 pontos)
Para quem está com pressa, este é o resumo.
- Struct é um tipo por valor. Ao copiar, ele se torna um valor completamente diferente.
- Classe é um tipo por referência. Mesmo após a cópia, as duas referências apontam para a mesma instância.
- Na dúvida, comece com struct; use class apenas quando precisar de herança ou estado compartilhado.
Lembrando destas três linhas, metade do caminho já está feita.
Qual é a diferença entre tipo por valor e tipo por referência?
Falando apenas assim, pode parecer confuso. O jeito mais rápido é ver no código.
Primeiro, as structs. No momento em que são copiadas, tornam-se independentes.
struct Point { var x = 0 }
var a = Point()
var b = a // Valor copiado
b.x = 10
print(a.x, b.x)
// Saída: 0 10Mesmo alterando b, a continua igual. Cada um tem seu próprio valor.
Agora, as classes. O código parece igual, mas o resultado é diferente.
class Box { var x = 0 }
let a = Box()
let b = a // Referência copiada (mesmo objeto)
b.x = 10
print(a.x, b.x)
// Saída: 10 10Alterei apenas b, mas a também passou a ser 10.
Isso acontece porque os dois apontam para a mesma instância. Esse era exatamente o bug que me incomodava.
Então, quando usar cada um? (Critérios de escolha)
Para decidir no trabalho, eu visualizo esta tabela.
| Situação | Decisão |
|---|---|
| Modelo que apenas armazena dados | Struct |
| Quero que as cópias sejam independentes | Struct |
| Herança é indispensável | Classe |
| A mesma instância é compartilhada em vários lugares | Classe |
| É necessário interoperar com Objective-C | Classe |
Em mais detalhes, o critério é este.
- Para representar o valor em si, como coordenadas, cores ou tamanhos, uma struct é natural.
- Quando vários lugares precisam observar um único estado compartilhado, como em um controlador de tela ou gerenciador de rede, a classe é adequada.
- O fato de o SwiftUI da Apple definir View como struct tem o mesmo motivo: é leve e previsível.
Por sinal, Array, String e Dictionary da biblioteca padrão do Swift são structs. Isso mostra como o tipo por valor é a opção padrão.
Por que recomendo começar com structs
Tipos por valor são fáceis de prever.
Você não precisa se preocupar que o valor passado seja alterado às escondidas em outro lugar. Mesmo ao passá-lo para uma função, o original permanece seguro.
Em ambientes multithread, eles também trazem tranquilidade. Como não há estado compartilhado, as condições de corrida de dados diminuem.
Já as classes são poderosas, mas exigem cuidado. Quando vários lugares mantêm a mesma instância, fica difícil rastrear onde o valor foi alterado.
Por isso, adotar “struct por padrão, class apenas quando necessário” reduz bastante os bugs.
Quando usar e quando evitar cada um
Por fim, resumi os critérios.
- Use structs: modelos centrados em dados, quando cópias independentes forem necessárias ou a segurança entre threads for importante.
- Use classes: quando precisar de herança, compartilhar uma instância ou quando a identidade tiver significado.
- Evite: usar class por hábito em modelos simples ou forçar uma solução com struct quando o compartilhamento for necessário.
É assim que perguntam em entrevistas
P. Qual é a maior diferença entre struct e classe?
Struct é um tipo por valor, enquanto classe é um tipo por referência. Ao copiar uma struct, você obtém um valor totalmente independente; ao copiar uma classe, as duas referências apontam para a mesma instância. Além disso, apenas classes permitem herança e podem ter um destrutor (deinit).
P. Por que o Swift recomenda o uso de structs?
Porque tipos por valor não têm estado compartilhado, geram menos efeitos colaterais e são mais previsíveis. O original não corre o risco de ser alterado sem intenção, e eles são seguros em ambientes multithread, ajudando a reduzir bugs.
No começo, eu também achava que era apenas uma diferença de sintaxe, mas quanto mais estudava, mais percebia que era uma questão de design.
Se você se acostumar com estes critérios, vai hesitar menos a partir do próximo projeto. Valor ou compartilhamento? Comece sempre por essa pergunta.