Estruturas de Dados

Estrutura de dados é o jeito que você organiza informação para o programa trabalhar com ela.

E sim: isso muda muito o resultado final.

A mesma regra pode virar:

• código limpo e rápido
• ou um caos cheio de busca lenta, duplicação e remendo

O erro mais comum do iniciante

Usar lista para tudo.

Lista resolve muita coisa? Resolve.

Mas não resolve tudo bem.

Quando você usa a estrutura errada, aparecem sintomas clássicos:

• busca linear em toda tela
• duplicação de lógica
• if demais para compensar modelagem ruim
• performance caindo sem você entender por quê

O que você precisa entender primeiro

Array / Lista

Boa quando:

• a ordem importa
• você percorre os dados em sequência
• acesso por índice faz sentido

Ruim quando:

• você precisa achar item por chave o tempo todo
• remove ou insere no meio com frequência alta

Stack

Modelo LIFO: o último que entra é o primeiro que sai.

Use quando o fluxo parece:

• desfazer ação
• histórico de navegação
• parsing
• chamadas aninhadas

Queue

Modelo FIFO: o primeiro que entra é o primeiro que sai.

Use quando o fluxo parece:

• fila de processamento
• tarefas pendentes
• mensagens
• processamento assíncrono

Map / Dicionário / HashMap

Use quando você quer:

• achar rápido por ID
• relacionar chave → valor
• evitar varrer lista toda hora

Exemplo:

• idUsuario -> objetoUsuario

Set

Use quando o ponto principal é:

• garantir unicidade
• descobrir se algo já existe

Exemplo:

• e-mails únicos
• tags sem repetição
• IDs já processados

Como escolher sem enrolação

Responde essas perguntas:

1. O acesso principal será por índice, chave, ordem ou prioridade?
2. Eu vou buscar muito ou iterar muito?
3. Preciso impedir duplicidade?
4. A ordem importa?
5. Vou processar em sequência?

Só essas perguntas já resolvem boa parte da escolha.

Mapa mental rápido

• quer percorrer em ordem? lista
• quer achar por chave? map
• quer unicidade? set
• quer processamento em fila? queue
• quer desfazer / voltar? stack

Simples assim.

Exemplo real: sistema de pedidos

No mesmo sistema, você pode ter:

• Array para exibir pedidos em ordem na interface
• Map para buscar pedido por ID rápido
• Queue para processar pedidos pendentes
• Set para impedir reprocessamento do mesmo evento

Repara no ponto importante:

um sistema sério usa mais de uma estrutura ao mesmo tempo.

Complexidade: o mínimo que você precisa sentir

Você não precisa decorar tudo agora.

Mas precisa sentir a diferença entre:

• procurar em lista item por item
• acessar direto por chave

Quando a base cresce, isso muda:

• tempo de resposta
• custo de processamento
• clareza do código

Quando a estrutura está errada

Sinais clássicos:

• você vive fazendo find, filter, some na mesma coleção
• toda função precisa “achar” o mesmo item de novo
• você cria lista paralela pra compensar falta de estrutura
• precisa de comentário demais para explicar como os dados se relacionam

Erros comuns

• usar lista para lookup por ID
• duplicar estado em várias estruturas sem estratégia
• esconder regra de negócio dentro da estrutura
• expor estrutura bruta em vez de encapsular comportamento

Encapsular é o pulo do gato

Não basta escolher estrutura boa.

Você também precisa evitar espalhar manipulação dela no projeto inteiro.

Melhor:

• adicionarPedido(pedido)
• buscarPedidoPorId(id)
• marcarPedidoComoProcessado(id)

Pior:

• cada arquivo mexendo direto no array, set e map

Exercícios que realmente ajudam

1. Monte um gerenciador de tarefas com lista e prioridade.
2. Use Map para acesso por ID.
3. Use Set para tags únicas.
4. Use Queue para tarefas pendentes.
5. Explique em voz alta por que cada estrutura foi escolhida.

Checklist rápido

• Você entende diferença entre lista, stack e queue?
• Você sabe quando map ganha de lista?
• Você percebe quando set evita bug?
• Você consegue justificar sua escolha de estrutura?

Se sim, você já começou a pensar como engenheiro, e não só como “quem faz funcionar”.

Próximas ações

• Vá para Lógica de Programação
• Depois conecte tudo em Algoritmos