Solucionado (ver solução)
Solucionado
(ver solução)
3
respostas

Atributos Dinâmicos

Apesar de ser benéfico e alguns pontos ter uma alteração dinâmica de classes, como funciona isso no dia a dia de Dev? É boa prática o uso do recurso?

Pergunto, pois ao meu ver, poderia em algum momento comprometer um debug de código, por exemplo, já que em outras partes poderíamos estar inserindo outros atribuitos.

Obrigado!

3 respostas

Olá Wander, tudo bem ?

Eu fiquei um pouco confuso com a sua pergunta, você quis dizer sobre durante o desenvolvimento mudar o tipo de uma variável, por exemplo:

o atributo Cliente em trecho do código ser uma String e depois um objeto do tipo Cliente, correto?

Neste caso realmente será uma má prática, por mais que o javacript tenha essa questão de variáveis de tipo dinâmicos, iremos querer ao máximo que uma variável nasça de um tipo e morra com aquele tipo ( seja em uma classe ou dentro do código, uma função)

E a razão é justamente essa que você comentou, fica muito mais difícil saber o fluxo de nossa aplicação e o que esperar, se em algum momento uma variável numérica pode se tornar um objeto com 10 atributos por exemplo :)

Por isso que é muito comum usarmos const para evitar redeclarações dentro de funções, e também é um dos motivos que o Typescript chamou atenção de alguns devs, pois você faz a tipagem dos atributos da classe e não permite essa dinamicidade :)

Então o ideal é sempre evitar que os tipos dos nosso atributos mudem dentro da nossa aplicação :)

Abraços e Bons Estudos!

Na verdade é relacionado à classe, orientação a objeto especificamente.

Dada a classe exemplo abaixo:

class Cliente {
nome;
cpf;
}

Como JS permite, que por exemplo, durante o código façamos:

const cliente = new Cliente();
cliente.nome = "José";
cliente.cpf = "1234"

cliente.nomeMae="Lourdes Lee";

Que exibirá:

Cliente { nome: 'José', cpf: '1234', nomeMae: 'Lourdes Lee' }

Esse tipo de recurso é utilizado com frequencia? Como lidar com isso no dia a dia de dev?

Perdão pela falta de exemplos, mas me empolguei em questionar logo. Acabou que ficou confuso! :)

solução!

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 awaitque 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!