Entendendo propriedade inerente em código e na vida real
Uma propriedade inerente é simplesmente aquilo que algo traz consigo sem precisar de configuração externa. Não é algo que você adiciona depois, é parte da definição. Quando você cria um objeto que representa um cachorro, o fato de ele ter quatro patas é inerente àquilo que é um cachorro. Não precisa de parâmetro, não precisa de if, está lá porque sim. Isso parece boba a primeira vista, mas na prática todo mundo erra isso de jeito errado. Eu já vi código onde alguém colocou um atributo "cor" como argumento obrigatório num construtor de classe de animal, quando na verdade a cor varia e não é inerente à espécie. O correto seria tornar opcional ou delegar para uma subclasse.
O que é algo inerente e por que a diferença importa
A questão chave é distinguir entre inerente e derivado. Inerente não surge de cálculo, não é resultado de função, não depende de estado externo. Já o derivado é calculado sob demanda a partir de outras propriedades. Um retângulo tem largura e altura inerentes. A área é derivada. Confundir esses dois conceitos gera bugs chatos que aparecem só em produção, quando alguém modifica uma propriedade e esquece que o valor derivado não se atualiza sozinho. No meu caso, eu trabalhei numa API de pagamentos onde havia um campo "taxa" que deveria ser inerente ao tipo de transação, mas estava sendo recalculado a cada request a partir de uma tabela de tarifas. O problema era que a tabela tinha atraso de sincronização de cerca de 30 segundos com o gateway. Resultado: clientes viam taxas diferentes na mesma sessão. A solução foi transformar a taxa em propriedade inerente ao momento da criação da transação, travando o valor naquele instante e nunca mais consultando a tabela. O sistema ficou mais simples e as reclamações caíram pela metade.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Outra coisa que pouca gente entende direito: inerência não é a mesma coisa que imutabilidade. Algo pode ser inerente e ainda assim mutável. Um usuário criado com um ID inerente pode ter o nome alterado depois. O ID continua sendo inerente porque nasce com o objeto, mesmo que o objeto como um todo mude. Na orientação a objetos moderna, frameworks como Django usam esse conceito de forma explícita com campos "auto_now_add" e similar. Você declara que determinado atributo é inerente ao momento de criação e o framework cuida do resto. Em vanilla JavaScript, você faria isso dentro do construtor com let ou const, sem exponencializar para fora. Em Rust, a ideia aparece naturalmente porque o sistema de tipos te obriga a decidir no momento da definição do struct o que é inerente versus o que é computado.
O erro mais comum é tratar tudo como parametrizável. Se você passar tudo como argumento, acaba com construtores com dezenas de parâmetros e código que fica frágil a mudanças. A regra prática é: se o valor não faz sentido sem o objeto existir, é inerente. Se o valor pode ser recalculado ou substituído sem destruir o objeto, provavelmente é derivado ou externo. Limitações existem. Quando você torna algo inerente, perde flexibilidade. Se no futuro precisar mudar aquele valor, vai precisar de um método de recriação ou de um sistema de migração. Em bancos de dados relacionais, columnas NOT NULL com DEFAULT funcionam bem para isso, mas se o valor inerente depender de uma regra de negócio complexa, o SQL puro não resolve — aí você precisa de triggers ou de lógica na application layer, o que reintroduz complexidade.
Também vale notar que inerência é relativa ao domínio. O que é inerente para um módulo pode ser derivado para outro. Num sistema de e-commerce, o preço de um produto pode ser inerente ao registro do item, mas derivado em relação ao carrinho, onde o preço final depende de cupons e condições de frete. Não existe resposta universal, só uma decisão de design consciente sobre onde a propriedade deve residir.
