É, realmente o substituto

Boa parte do que aprendi já não lembro, mas uma coisa nunca esqueci: “o número Pi é mais que irracional, é transcendental!”

E nos embrenhávamos nessa mata sem lanternas. Foi um semestre sem ver um gráfico que representasse o que provávamos. Aliás, no último mês um colega pergunta se ele poderia desenhar, no que ele responde “pois não”. (Ué, bastava pedir?!)

Era como atravessar mata fechada. Uma vez, mais de uma hora de equações que não fazia ideia de onde iam dar, chegamos a uma clareira: o número de Euler (ele escreve de cor mais de uma dezena das casas decimais).

Óculos fundo-de-garrafa, camisa branca e calças cinza eram o seu uniforme. Pontualmente iniciava e pausava a aula para fumar. No quadro ia e vinha um grande trem de pensamentos matemáticos. A pausa nunca foi suficiente para alcançar o bonde perdido.

Não é um pensamento novo. Nós desenvolvedores lidamos com isso diariamente, até construímos linguagem com o objetivo de permitir ou restringir certas ações (Rust, anyone?). Mas é engraçado ver acontecendo!

Enquanto tagueava minhas notas, percebi que se usava Desenvolvimento de Software ao invés de Software Development um conjunto completamente diferente de memórias e sensações surgiam.

O idioma que escolhi para _categorizar_ impacta o que vou gerar a partir dessas notas.

Se considerarmos que DRY se refere a não repetir o conceito, separamos as classes de antemão pois não representam a mesma coisa.

Outro caminho é o sugerido no artigo: voltar atrás quando surgir a primeira mudança. Mas vale ter em mente que pode ser difícil vencer a inércia.

É como a história do sapo na água sendo aquecida. Cada mudança é um incremento pequeno na temperatura que é difícil justificar sair da água, até que é tarde demais.

Ao fim se tem uma mesma classe que é usada de forma diferente em cada parte do código. Fácil, fácil de errar, sobretudo para quem conhece pouco o sistema.

Em seguida, é necessário ter uma representação de mais alto nível que a do banco de dados de um dos campos. Agora o código precisa garantir que os dois campos estão em sincronia e controlar quais campos vão para o banco ou são retornados na resposta.

Então, em um dado momento surge um endpoint para atualização da entidade, mas nem todo campo é atualizável. Agora o código precisa lidar com o fato de que o objeto pode não ter todos os campos preenchidos corretamente.

Também imagine que o sistema poderia ser criado em cima de um exemplo do framework. Não é incomum que o código de exemplo seja exatamente assim.

Parece uma má decisão, mas imagine que o sistema poderia ser mais simples no início. Criar de antemão classes separadas que tem o mesmo conteúdo seria entendido como duplicação de código.