Aaaaa agora fez mais sentido hahaha!
Então, agora estamos falando de algo um pouco mais comum, mas que eu vejo não sendo também tãaaao utilizado
Com os setters
a gente consegue proteger a nossa informação de ter dados inválidos, então não nos atrapalha no quesito de não saber o que esperar daquele atributo, por outro lado, não é comum ficar mudando o valor de variáveis
Um principio muito legal e que diversas vezes você vai se deparar é com a imutabilidade, então normalmente iremos privilegiar receber as informações via construtor e criar um objeto que seja correto, e trabalhar com a menor quantidade possível de parâmetros que possam ser alterados =)
Mas existem situações em que queremos receber um dado posterior a criação do objeto, ai com certeza será necessário utilizar, mas ai temos controle do fluxo da nossa aplicação para saber em que momento é adicionado ou não aquela propriedade :)
Mas vou dar um exemplo que pode ser comum, hoje em dia temos o TypeORM
que mapeias as nossas classes para o banco de dados, para fazer um update
utilizando ele temos um código mais ou menos assim:
const cliente = await repositorioDeClientes.find(1);
cliente.email = "novoEmailDoCliente@alura.com.br"
await repositorioDeClientes.save(cliente)
Não preicsa ligar para o await
que na parte de javascript avançado é abordado :)
Mas esse é um código onde buscamos um cliente com id
1, e utilizamos o .email
para mudar o valor e salvar novamente
Mas foi como eu disse, iremos querer a imutabilidade na maioria das vezes que possível, mas certamente haverá momentos em que será necessário fazer alguma alteração nesse sentido :)
Abraços e Bons Estudos!