Imutável quer dizer que o dado é constante e nunca muda?

Não exatamente. A variável pode passar a apontar para outro valor; o que não muda é o valor em si. Você não altera a lista antiga, você cria uma nova e faz a variável apontar para ela. O objeto original fica intacto para quem ainda o segura. É a diferença entre trocar o conteúdo da caixa e pegar uma caixa nova.

Copiar tudo a cada alteração não deixa o programa lento?

Pode pesar em pontos muito quentes, mas na maioria dos casos o custo é irrelevante perto da clareza que traz. E existem estruturas imutáveis espertas que compartilham as partes que não mudaram, copiando só o necessário. Para a maior parte do código, a previsibilidade compensa o custo. Onde a performance for crítica, você mede e decide caso a caso.

Então nunca devo mutar nada?

Mutar é seguro quando o dado é local e ninguém mais o enxerga. Um acumulador dentro de um laço, uma lista temporária que você monta e devolve pronta, tudo isso pode ser mutado sem risco. O perigo é mutar dado que veio de fora ou que outros trechos guardam. A regra é: mute o seu rascunho, respeite o que é dos outros.

Como sei se uma operação muta ou copia?

O nome ajuda muito. Verbos crus, como adicionar, remover ou ordenar, costumam mexer no original. Nomes que sugerem um resultado novo, como ordenada, comItem ou semUltimo, costumam devolver uma cópia. Na dúvida, a documentação da linguagem diz se a operação altera o objeto ou retorna um novo. Vale conferir antes de confiar.

Isso tem a ver com passar dado por valor ou por referência?

Tem tudo a ver. Quando você passa uma lista mutável para uma função, muitas linguagens passam a referência, ou seja, a própria lista, não uma cópia. Se a função a altera, o efeito volta para quem chamou. Tratar o dado como imutável dentro da função, criando uma versão nova em vez de mexer no recebido, elimina essa surpresa.

Textos e números são mutáveis ou imutáveis?

Depende da linguagem, mas números e textos costumam ser imutáveis: somar ou concatenar gera um valor novo, sem alterar o antigo. Listas e dicionários, por outro lado, costumam ser mutáveis. Saber quais tipos da sua linguagem são de cada categoria evita muita confusão, porque muda o comportamento ao passar esses dados adiante.

Módulo 14 - Imutabilidade e efeitos: código previsível

Mutável ou imutável: mudar no lugar ou copiar

8 min de leitura · por Cesar Gargiulo, revisado pela equipe ValorFinal e GuardiaSec · Atualizado em 12/07/2026

Velocidade

O que você vai aprender

Diferenciar mudar um dado no lugar de gerar uma cópia alterada.
Reconhecer o risco de compartilhar um dado mutável entre vários trechos.
Listar as vantagens práticas da imutabilidade.
Decidir quando copiar compensa e quando mutar é aceitável.

Duas formas de alterar um dado

Imagine uma lista de compras. Você tem duas maneiras de acrescentar um item. Na primeira, pega a folha que já existe e escreve o item no fim: a folha original agora está diferente, e quem tiver uma cópia dessa mesma folha na mão vê a alteração. Na segunda, você copia a lista inteira para uma folha nova, escreve o item na cópia e guarda a original numa gaveta, sem tocá-la. Nos dois casos você fica com uma lista que tem o item a mais, mas o efeito sobre o mundo é outro. A primeira forma é a mutação, mudar no lugar. A segunda é a via imutável, gerar uma cópia e preservar o passado.

Essa diferença parece filosófica até o dia em que morde. Dado mutável tem uma armadilha silenciosa: quando dois trechos do programa apontam para a mesma lista, um deles pode alterá-la sem que o outro saiba. O segundo trecho continua achando que a lista está do jeito antigo e toma decisões erradas. Com dado imutável isso não acontece, porque ninguém consegue mexer no valor que você tem na mão; qualquer alteração vira um objeto novo, separado. É por isso que muita gente prefere a imutabilidade em partes sensíveis do sistema, mesmo pagando o custo de copiar.

Dois caminhos partindo de uma mesma lista [a, b, c]. No caminho de cima, rotulado mutável, uma seta acrescenta d à própria lista, que passa a ser [a, b, c, d], e uma segunda referência que apontava para a lista original agora também vê [a, b, c, d]. No caminho de baixo, rotulado imutável, a operação cria uma lista nova [a, b, c, d] enquanto a original [a, b, c] permanece intacta na gaveta. — Mutar altera o original e afeta quem compartilha; imutar cria uma cópia nova e preserva o antigo.

O perigo do dado compartilhado

O problema clássico aparece quando você acha que está passando uma cópia, mas está passando a mesma lista. Um trecho recebe a lista, adiciona algo achando que trabalha num rascunho particular, e sem querer altera o dado que a tela ainda está mostrando. O usuário vê itens surgirem do nada. Rastrear esse bug é penoso porque a causa fica longe do efeito: quem mutou o dado não é quem exibe o erro. Com a mentalidade imutável, a regra vira simples: nunca altere o que recebeu; se precisa de uma versão diferente, crie uma nova e devolva. Assim, o dado de quem chamou fica intocado, e o efeito mora só no retorno.

lista <- ["pão", "leite"]
// via mutável: mexe no original
adicionarNoLugar(lista, "ovo")
// agora lista virou ["pão", "leite", "ovo"] para TODOS que apontam para ela

// via imutável: devolve uma cópia nova
nova <- comItemAMais(lista, "café")
// lista continua ["pão", "leite", "ovo"]; nova é ["pão", "leite", "ovo", "café"]

A versão imutável não toca em lista; monta e devolve nova. O original fica previsível.

🎮 Jogo da aula

Muda no lugar ou gera cópia?

Cada operação altera o dado original ou devolve uma cópia nova sem tocar no original? Classifique nos dois baldes.

Quando copiar compensa e quando mutar é aceitável

A imutabilidade não é uma regra absoluta, é uma troca. Copiar gasta tempo e memória, e em laços muito quentes, que rodam milhões de vezes, criar um objeto novo a cada volta pode pesar. Nesses pontos, mutar um dado local, que ninguém mais enxerga, é aceitável e às vezes necessário. O que faz mal é a mutação de dado compartilhado, aquele que outros trechos guardam. A regra prática que evita a maioria dos bugs: mute à vontade dados que nasceram e morrem dentro da mesma função, mas trate como imutável tudo que você recebeu de fora ou vai devolver. Assim você ganha a previsibilidade onde ela importa e a velocidade onde ela conta.

Teste rápido

Por que dado mutável compartilhado entre vários trechos costuma gerar bugs difíceis de achar?

Perguntas frequentes

Imutável quer dizer que o dado é constante e nunca muda?: Não exatamente. A variável pode passar a apontar para outro valor; o que não muda é o valor em si. Você não altera a lista antiga, você cria uma nova e faz a variável apontar para ela. O objeto original fica intacto para quem ainda o segura. É a diferença entre trocar o conteúdo da caixa e pegar uma caixa nova.
Copiar tudo a cada alteração não deixa o programa lento?: Pode pesar em pontos muito quentes, mas na maioria dos casos o custo é irrelevante perto da clareza que traz. E existem estruturas imutáveis espertas que compartilham as partes que não mudaram, copiando só o necessário. Para a maior parte do código, a previsibilidade compensa o custo. Onde a performance for crítica, você mede e decide caso a caso.
Então nunca devo mutar nada?: Mutar é seguro quando o dado é local e ninguém mais o enxerga. Um acumulador dentro de um laço, uma lista temporária que você monta e devolve pronta, tudo isso pode ser mutado sem risco. O perigo é mutar dado que veio de fora ou que outros trechos guardam. A regra é: mute o seu rascunho, respeite o que é dos outros.
Como sei se uma operação muta ou copia?: O nome ajuda muito. Verbos crus, como adicionar, remover ou ordenar, costumam mexer no original. Nomes que sugerem um resultado novo, como ordenada, comItem ou semUltimo, costumam devolver uma cópia. Na dúvida, a documentação da linguagem diz se a operação altera o objeto ou retorna um novo. Vale conferir antes de confiar.
Isso tem a ver com passar dado por valor ou por referência?: Tem tudo a ver. Quando você passa uma lista mutável para uma função, muitas linguagens passam a referência, ou seja, a própria lista, não uma cópia. Se a função a altera, o efeito volta para quem chamou. Tratar o dado como imutável dentro da função, criando uma versão nova em vez de mexer no recebido, elimina essa surpresa.
Textos e números são mutáveis ou imutáveis?: Depende da linguagem, mas números e textos costumam ser imutáveis: somar ou concatenar gera um valor novo, sem alterar o antigo. Listas e dicionários, por outro lado, costumam ser mutáveis. Saber quais tipos da sua linguagem são de cada categoria evita muita confusão, porque muda o comportamento ao passar esses dados adiante.

Fontes

Seu progresso fica salvo neste aparelho. Assinantes sincronizam entre os aparelhos.

← Invariantes: a promessa que o código mantém Concluir e avançar →