Generalização Poo: guia técnico para uso com segurança

O que é Generalização Poo e por que importa na prática

Generalização Poo é um conceito central em projetos orientados a objetos que permite organizar responsabilidade de forma hierárquica, criando tipos mais gerais que favorecem reuso, consistência e manutenção. Em vez de repetir regras e contratos em várias classes, você define o comportamento em um nível “base” e especializa quando necessário. O resultado esperado é um design mais coerente e fácil de evoluir, com impacto direto na testabilidade e na clareza do sistema.

Na prática profissional, a Generalização Poo ajuda a:

• reduzir duplicações (DRY), evitando que a mesma lógica seja reaplicada em múltiplos pontos;
• padronizar interfaces e comportamentos, melhorando previsibilidade para quem usa a API;
• permitir polimorfismo com contratos bem definidos, de modo que diferentes implementações possam ser tratadas de forma uniforme;
• tornar mudanças futuras mais localizadas, concentrando alterações no nível onde o “comum” realmente está.

Porém, para colher esses ganhos, é crucial evitar generalizações frágeis (quando a classe base vira um “depósito” de casos especiais) e manter invariantes claros. Uma hierarquia mal desenhada produz o efeito oposto: duplicação disfarçada, exceções frequentes, testes frágeis e custos de manutenção crescentes.

Em outras palavras, generalizar é mais do que herdar: é modelar um modelo mental do domínio. Quando a abstração representa corretamente o que é comum aos subtipos, o sistema fica mais fácil de compreender e alterar. Quando não representa, a hierarquia se transforma em um labirinto de exceções, sobreposições e “regras que só funcionam às vezes”.

Entendendo o papel do “geral” no desenho orientado a objetos

Em arquiteturas bem cuidadas, a Generalização Poo não é apenas uma decisão de código; é uma decisão de modelagem. Você está escolhendo como representar entidades e responsabilidades: o que deve ser comum, o que deve variar e como as variações devem ser encapsuladas. Esse cuidado tende a melhorar a legibilidade e reduzir erros de manutenção ao longo do tempo.

Um jeito útil de pensar nisso é visualizar a herança como uma ferramenta para expressar substituibilidade: se um objeto do tipo mais específico pode ser usado no lugar do tipo mais geral sem o consumidor “perceber”, então existe um relacionamento semântico verdadeiro. Se o consumidor precisa fazer casts, usar if/else por tipo concreto, ou tratar exceções que “normalmente não deveriam acontecer”, você provavelmente não tem uma generalização adequada; você tem apenas uma tentativa de reutilização superficial.

Um ponto comum em ambientes corporativos é que sistemas crescem por adição contínua de funcionalidades. Quando a estrutura de classes não prevê evolução, surgem “ilhas” de lógica duplicada, e mudanças precisam ser aplicadas em muitos lugares. Ao usar Generalização Poo com disciplina—criando abstrações que realmente representam o domínio—o impacto dessas mudanças costuma ficar mais controlado. A equipe consegue evoluir sem estar constantemente “caçando” implementações espalhadas.

Considere também o efeito cognitivo: em sistemas grandes, a manutenção não falha apenas por código duplicado; falha por incerteza. Um bom modelo de generalização reduz incerteza porque há uma forma consistente de explicar o sistema. Quando um desenvolvedor novo entra no time, ele aprende primeiro os contratos do nível geral e depois entende como cada subtipo preserva (ou especializa) esse comportamento. Isso diminui a curva de aprendizado e a chance de “reinventar” comportamentos.

Como aplicar Generalização Poo sem criar acoplamento desnecessário

Para um especialista, a pergunta-chave não é apenas “onde usar herança?”, mas “qual abstração é semanticamente correta?”. A generalização deve expressar um contrato estável: invariantes, pré-condições e pós-condições do comportamento esperado. Se isso não existir, a “classe base” vira uma convenção artificial, o que mina manutenção.

Um erro comum em equipes em crescimento é tratar herança como “um jeito de compartilhar código”, sem se preocupar com o que torna o relacionamento verdadeiro. Quando isso acontece, o resultado é o famoso problema da classe base que “sabe demais”, ou seja, uma superclasse que assume responsabilidades variadas e depois tenta corrigir exceções por meio de condicionais, variáveis de estado internas ou métodos que retornam comportamentos que só fazem sentido para alguns subtipos.

Boas práticas frequentemente observadas em equipes maduras:

• Preferir o que é realmente comum: extraia apenas comportamentos que todos os subtipos compartilham de forma coerente. “Parecido” não é sinônimo de “comum”.
• Evitar classe base que sabe demais: se a base precisa de flags e switches para tratar variações, provavelmente a generalização está incompleta ou mal segmentada.
• Projetar para substituição: subtipos devem poder ser usados onde o tipo geral é esperado, sem quebrar contratos. Isso normalmente implica que invariantes sejam preservadas.
• Manter interfaces coesas: a generalização deve reduzir ruído, não espalhar responsabilidades em “camadas” ambíguas. Interfaces coesas tornam o design mais fácil de testar e documentar.
• Proteger encapsulamento: expor demais na classe base aumenta o acoplamento. O ideal é expor apenas o necessário para cumprir o contrato.
• Tratar falhas como parte do contrato: erros e exceções também fazem parte do comportamento. Se um subtipo lança exceções específicas que o consumidor não espera, a substituição falha.

Generalização Poo e polimorfismo: ganhos concretos

Quando a generalização está bem desenhada, o polimorfismo se torna uma ferramenta previsível. Você trata objetos por um tipo geral e permite que a execução “escolha” o comportamento correto em tempo de execução. Isso é especialmente útil em sistemas com variação por contexto (por exemplo, diferentes estratégias de cálculo, diferentes tipos de processamento ou diferentes regras de validação).

Uma forma prática de enxergar o valor é observar o que acontece quando você adiciona um novo subtipo. Se a generalização está correta, você costuma:

• implementar o subtipo seguindo o contrato;
• registrar ou instanciar a implementação em algum lugar (por exemplo, em um factory ou através de injeção de dependência);
• não precisar modificar o “consumidor” (código que usa o tipo geral), desde que os contratos sejam respeitados.

Isso é especialmente relevante em arquiteturas que exigem extensibilidade. Em vez de abrir o consumidor para cada novo caso (violando o princípio aberto/fechado), você fecha o comportamento no consumidor e abre apenas as implementações (subtipos). Em termos de mudança, a generalização bem feita tende a reduzir o número de pontos afetados.

Entretanto, a generalização não pode ser um atalho para contornar design ruim. Se o tipo geral abrange comportamentos que não fazem sentido para certos subtipos, você cria exceções frequentes, métodos “vazios” ou exceções em runtime. Isso aumenta custo de depuração e reduz confiança no sistema. Quando isso ocorre, você normalmente precisa refazer o modelo: separar hierarquias, decompor responsabilidades ou deslocar partes do comportamento para composição.

Também é importante diferenciar dois cenários que parecem semelhantes:

• Generalização correta: um subtipo realmente é um “tipo” do geral. Ele respeita invariantes e contrato.
• Compartilhamento forçado: dois componentes compartilham código, mas semanticamente não fazem o mesmo papel do domínio. Aqui, herança costuma ser uma solução equivocada.

No segundo cenário, o que você realmente precisa é de outra forma de reutilização (por exemplo, composição, delegação, ou extração de utilitários/padrões). Caso contrário, você prende o design a uma taxonomia artificial.

Onde Generalização Poo costuma falhar (e como identificar cedo)

Em projetos reais, a Generalização Poo pode falhar por sinais visíveis, como:

• Subclasses com muita lógica condicional: quando a variação está “espalhada” no código do subtipo, é possível que a hierarquia não esteja representando corretamente o domínio. Por exemplo, o subtipo faz if/else com base em “tipos internos” que deveriam ser modelados como subtipos separados.
• Métodos herdados que não são aplicáveis: um indício clássico de abstração inadequada é o subtipo “forçado” a implementar algo que ele não deveria. Se ele precisa lançar exceção do tipo “not supported”, você provavelmente violou substituibilidade.
• Hierarquias profundas demais: profundidade excessiva dificulta entendimento e aumenta chance de efeitos colaterais em mudanças. Além disso, herança profunda tende a dificultar testes, porque mudanças na base podem ter efeitos inesperados.
• Fragilidade ao evoluir: pequenas alterações em um nível “base” exigem ajustes em vários subtipos. Isso pode indicar que a classe base não estabilizou contratos ou que a base não encapsula o “comum” real.
• “Base inchada”: superclasses com muitos métodos, estados e responsabilidades que não são verdadeiramente universais. Isso geralmente é resultado de generalização prematura ou de tentativa de acomodar requisitos futuros.
• Alterações frequentes por causa de exceções: se toda mudança vira uma cascata de correções por causa de comportamentos especiais na hierarquia, a abstração não está estável.

Para correção, especialistas costumam reavaliar o que é de fato comum e redistribuir responsabilidades. Em alguns casos, a solução não é “refinar herança”, mas separar responsabilidades por composição, interfaces ou padrões de projeto adequados. Às vezes, inclusive, a melhor decisão é remover herança e reaprender a construir o modelo por abstrações menores e contratos mais específicos.

Há também indícios menos óbvios. Por exemplo, se a equipe começa a documentar exceções do tipo “este método só funciona em X”, você já tem um cheiro de que o contrato não está sendo cumprido de forma universal. Quando contrato depende de contexto implícito, você perde parte do valor da substituição.

Outro sinal é quando a hierarquia começa a “ditar” detalhes de implementação ao invés do comportamento. Se a base exige que subtipos sigam um fluxo rígido que não faz sentido para todos, você pode estar tentando encaixar variações em um molde único. Nesses casos, vale considerar padrões como template method com cuidado (somente quando o fluxo realmente é comum), estratégia (para variações ortogonais), ou composição (para separar preocupações que mudam por motivos diferentes).

Uma comparação prática: abordagem baseada em generalização vs. alternativas

Abaixo, uma comparação objetiva para orientar decisões. Esta seção também serve como checagem rápida de alinhamento com condições típicas de engenharia de software.

Uma forma de usar esse quadro na prática é avaliando “qual mudança dói mais”: se a mudança mais frequente é nos comportamentos comuns (ou nas validações comuns), uma base bem desenhada ajuda. Se as mudanças mais frequentes são em aspectos ortogonais (por exemplo, regras diferentes que mudam por contexto), então interfaces e estratégia/composição podem ser mais adequadas.

Além disso, em muitos projetos modernos, o padrão não é “herança ou nada”. É “herança quando o relacionamento é semanticamente verdadeiro”, combinada com composição quando as variações são ortogonais. O equilíbrio é que determina a qualidade final do design.

Exemplo mental: como contratos moldam a hierarquia

Mesmo sem código específico, dá para ilustrar a ideia com um “contrato” conceitual. Imagine um sistema de pagamento em que existe a entidade Pagamento e subtipos como PagamentoCartao, PagamentoBoleto e PagamentoPix. A generalização faz sentido se:

• Todos os pagamentos têm um ciclo de vida semelhante (por exemplo, criar, autorizar, confirmar ou falhar).
• Existe um conjunto de invariantes compartilhado (por exemplo, valor não pode ser negativo, moeda deve ser válida).
• Existe substituibilidade: se o consumidor precisa apenas de “um pagamento” para registrar status e consultar eventos, ele pode receber qualquer subtipo e obter comportamento consistente.

Se, por outro lado, um dos meios de pagamento não segue o ciclo de vida previsto (por exemplo, “pix” confirma instantaneamente enquanto “boleto” depende de processo assíncrono), ainda é possível modelar isso com generalização—mas a base precisa expressar o contrato de forma adequada (por exemplo, contratos de status que contemplam processos assíncronos). Se a base assume sincronismo e depois cada subtipo “contorna” isso, você cria fragilidade.

Nesse exemplo, a generalização correta é a que define o mínimo comum que todos respeitam de forma consistente. Detalhes de variação ficam na especialização ou em componentes associados.

Fontes e referências para embasar as boas práticas

Este guia se apoia em princípios amplamente aceitos na engenharia de software e em documentação acadêmica/industrial consolidada, especialmente sobre desenho orientado a objetos e substituição comportamental:

• Princípios de substituição e qualidade de design associados ao Liskov Substitution Principle (exposto por Barbara Liskov no contexto de linguagens e abstrações). Em termos práticos, esse princípio ajuda a garantir que o comportamento definido pela superclasse seja preservado pelos subtipos.
• Práticas de design e arquitetura descritas em literatura clássica de padrões e arquitetura de software, incluindo discussões sobre quando herança é apropriada e quando composição/estratégia são melhores.
• Documentação técnica oficial de linguagens e frameworks (para regras de herança, tipagem e contratos), que pode variar conforme a linguagem (por exemplo, regras de variância, visibilidade e mecanismos de extensão).

Observação: Como você não forneceu preços, fornecedores, ou localidade específica, este artigo não inclui dados de custo nem nomes de fornecedores. O foco permanece em Generalização Poo como prática de projeto.

Se a sua implementação estiver em uma linguagem específica (Java, C#, TypeScript, Kotlin etc.), recomenda-se verificar detalhes da linguagem: por exemplo, como a linguagem lida com métodos abstratos, visibilidade, herança múltipla (ou ausência), contratos e anotações. Esses detalhes influenciam como você escreve invariantes e como testes detectam violação de substituição.

Guia passo a passo para aplicar Generalização Poo com disciplina

A seguir, um roteiro prático com condições/requirements típicos para evitar erros comuns.

1. Defina o domínio e as responsabilidades: descreva o que deve ser comum e o que deve variar. Se a “base” não expressa um conceito real do domínio, reavalie a generalização. Um bom teste mental é perguntar: “Se eu remover essa hierarquia, o domínio ainda faz sentido?” Se a resposta é “não”, a abstração provavelmente é útil. Se for “sim, mas só reapareceria a duplicação”, talvez você tenha generalizado por conveniência.
2. Estabeleça contratos claros: invariantes, pré-condições e pós-condições do comportamento. Isso guia tanto a implementação quanto os testes. Contratos podem incluir também: regras de validação, expectativas sobre estado interno e garantias de consistência.
3. Escolha o nível correto de generalização: evite subir abstrações demais. A classe base deve agrupar apenas o que faz sentido para todos os subtipos. Uma técnica útil é desenhar primeiro a lista do “comum” e remover itens que não sejam verdadeiros para todos.
4. Implemente o comportamento comum: métodos padrão e validações compartilhadas devem viver na base, sempre que forem verdadeiramente universais. Se a base precisar de “atalhos” que mudam comportamento por flags, é sinal de que o comum não está tão comum assim.
5. Modelagem das variações: use métodos abstratos, overriding bem definido ou mecanismos de extensão. Evite que variações dependam de flags e switches. Se o algoritmo muda por motivos ortogonais, considere separar por estratégia ou composição em vez de empilhar variações na herança.
6. Valide substituibilidade: verifique se um subtipo pode ser usado em qualquer contexto que exija o tipo geral, sem quebrar pressupostos. Isso inclui considerar exceções e estados: se o subtipo não consegue fornecer o mesmo contrato de erro (por exemplo, lançar exceções diferentes ou retornar estados inválidos), substituição pode estar falhando.
7. Crie testes orientados ao contrato: testes de unidade e testes por cenários devem validar comportamento esperado no nível de generalização. Uma abordagem é criar testes “genéricos” para a classe base (ou para uma interface/contrato) e executá-los para cada subtipo.
8. Revise a hierarquia ao longo do tempo: se surgirem exceções frequentes ou métodos herdados não aplicáveis, reestruture a hierarquia. Muitas vezes, a mudança mais importante vem quando você identifica “o comum” errado: é sinal de que a taxonomia precisa ser reorganizada.

Condições e requisitos recomendados (checklist)

• Condição 1: a superclasse/abstração deve representar um contrato estável e coerente. Se o contrato muda muito, sua base não está estabilizando o domínio.
• Condição 2: subtipos devem cumprir invariantes sem exigir tratamento especial pelo consumidor do tipo geral. Se o consumidor precisa “saber demais”, o contrato não está bem definido.
• Condição 3: mudanças no “comum” não devem forçar refatorações amplas inesperadas. Isso envolve avaliar como o comportamento é reutilizado e como o acoplamento foi criado.
• Condição 4: a hierarquia não pode “compensar” falhas de design com lógica condicional excessiva. Condicionais em cascata dentro do modelo indicam que a estrutura não representa bem o domínio.
• Condição 5: documentação técnica deve registrar intenções da generalização (por que existe, o que deve ser comum, e como estender). Sem documentação, a equipe interpreta o modelo de forma divergente e tende a criar exceções que “viram regra”.
• Condição 6: existam critérios objetivos para adicionar novos subtipos. Sem critérios, cada novo caso pode “forçar” a hierarquia a acomodar coisas que não pertencem.

Relação com qualidade de software: manutenção, testes e evolução

Na perspectiva de engenharia, Generalização Poo costuma beneficiar três dimensões: manutenção, testabilidade e evolução.

Manutenção: quando responsabilidades comuns ficam centralizadas, a correção de defeitos e a evolução de regras tende a demandar menos pontos de mudança. Isso não significa que “nunca” haja impacto; significa que o impacto tende a ocorrer no nível certo. Em um bom design, uma correção no comportamento comum aparece uma vez, e os subtipos herdam o conserto sem precisar de alteração.

Testabilidade: contratos definidos na base tornam testes mais estáveis. Você consegue escrever testes de comportamento no nível do tipo geral e validar que subtipos preservam o comportamento. Em geral, isso reduz fragilidade de testes porque você valida invariantes, e não detalhes acidentais de implementação.

Evolução: ao introduzir novos subtipos, a curva de integração diminui, desde que a generalização esteja correta e os contratos sejam respeitados. O consumidor do tipo geral tende a continuar funcionando, porque ele foi desenhado para o contrato.

Contudo, esses ganhos são condicionais. Se a generalização for “genérica demais”, o sistema fica difícil de entender. A equipe pode passar a temer mudanças por causa de efeitos colaterais. Portanto, o desenho de generalização precisa ser guiado por semântica do domínio e por critérios de substituição.

Uma forma de garantir que a generalização permaneça útil é acompanhar métricas qualitativas, por exemplo:

• Frequência de override: muito override pode ser normal (se a variação for grande), mas se a base define muitos comportamentos não compartilhados, talvez seja necessário refinar.
• Quantidade de exceções “não suportado”: se isso aparece com frequência, substituibilidade pode estar falhando.
• Complexidade ciclomática em subtipos: se cada subtipo tem condicionais complexas para “desfazer” comportamento herdado, talvez a base não represente o comum.
• Taxa de mudanças na base: se a base muda com frequência por causa de casos especiais, ela provavelmente não está estável.

Boas práticas adicionais para especialistas

• Evite herança por conveniência: se a motivação for apenas “economizar código”, pode ser uma composição ou uma interface que resolve melhor. Herança deve expressar relação semântica, não apenas reutilização.
• Refine nomes e responsabilidades: classes genéricas devem ter nomes que expressem papéis claros no modelo. Nomes ambíguos (“BaseManager”, “GenericHandler”) frequentemente são sintoma de generalização sem intenção semântica.
• Consistência de exceções e erros: contratos de tratamento de falhas também fazem parte da substituição. Documente e teste. Uma classe base não deve “prometer” um tipo de falha se subtipos lançam coisas diferentes ou inconsistentes.
• Cuidado com estado compartilhado: o estado na classe base pode introduzir acoplamento forte e efeitos colaterais. Se o estado interno precisa ser manipulado por subtipos, prefira expor métodos bem definidos (com contrato) em vez de permitir acesso amplo ao estado.
• Visibilidade e encapsulamento: o tipo geral deve expor apenas o necessário para permitir substituição sem quebrar invariantes. Uma prática é manter campos privados e expor apenas métodos que respeitam o contrato.
• Monitore “code smells”: longos if/else em subtipos, métodos herdados inutilizáveis e mudanças frequentes na base são sinais de reavaliação.
• Use testes contratuais: para sistemas críticos, considere testes de contrato que validem invariantes em diferentes implementações. Isso reduz regressões quando a hierarquia evolui.
• Evite fragilidade por chamadas internas: em alguns designs, a classe base chama métodos “overridable” durante o construtor ou inicialização. Dependendo da linguagem, isso pode produzir estados não inicializados. A regra prática é garantir que o ciclo de vida seja seguro e que o contrato de inicialização seja claro.
• Considere escalabilidade do design: em sistemas com muitas variações, talvez seja mais sustentável usar hierarquias menores e combinar com composição. A escalabilidade não é apenas “quantidade de classes”, é facilidade de entender as relações e evoluir sem quebrar contratos.

Estratégias para documentar a generalização de forma que a equipe siga

Um dos maiores desafios na prática não é “como escrever a hierarquia”, mas “como garantir que a equipe futura entenda a intenção”. Se você documenta apenas os nomes das classes e o método herdado, a equipe pode inferir o contrato de forma equivocada.

Uma documentação útil para generalização costuma incluir:

• Intenção semântica: o que o tipo geral representa no domínio (não apenas a função técnica). Ex.: “Payment é qualquer pagamento que passa por um ciclo de estados padrão”.
• Invariantes: regras que devem permanecer verdadeiras após cada operação pública. Ex.: “o valor do pagamento não pode mudar após ser criado”.
• Pré-condições e pós-condições: o que precisa estar válido quando um método é chamado e o que deve ser garantido quando ele termina.
• Como estender: quais métodos devem ser sobrescritos, quais não devem, e que invariantes devem ser preservadas ao fazê-lo.
• Tratamento de falhas: que tipos de erros podem ocorrer, em quais condições, e quais garantias o sistema mantém após uma falha.

Quando esse conteúdo existe, a equipe tende a reduzir divergência de interpretação e, consequentemente, reduz a chance de surgirem subtipos que “quebram” a substituibilidade.

FAQs sobre Generalização Poo

1) Generalização Poo significa sempre usar herança?

Não necessariamente. Na prática, Generalização Poo refere-se a como modelar abstrações mais gerais em orientação a objetos. Dependendo da linguagem, isso pode envolver herança, interfaces ou outros mecanismos que expressem contrato e substituibilidade. Em alguns casos, uma interface + composição expressa melhor o “geral” do que uma hierarquia de classes.

2) Como saber se a classe base está “inchando”?

Quando surgem muitos casos condicionais na superclasse, exceções frequentes para tratar particularidades ou métodos que não fazem sentido para todos os subtipos, geralmente a generalização perdeu foco e precisa ser reestruturada. Um método prático é revisar quantas responsabilidades diferentes estão sendo acomodadas e perguntar: “Isso é realmente comum ao domínio do tipo geral ou estou tentando empilhar funcionalidades?”

3) Generalização Poo ajuda em testes?

Sim. Ao definir contratos no nível geral e manter substituibilidade, testes podem validar comportamento esperado independentemente do subtipo. Isso tende a reduzir fragilidade dos testes e melhorar cobertura por cenários. Além disso, em arquiteturas com dependências injetadas, contratos bem definidos facilitam criação de doubles/mocks para testes.

4) Em que situações a generalização pode atrapalhar?

Quando a abstração não representa o domínio de forma consistente, levando a métodos herdados não aplicáveis, hierarquias profundas sem propósito claro ou mudanças que “vazam” da base para muitos subtipos. Em particular, quando você começa a adicionar “casos especiais” na base, frequentemente está corrigindo uma falha de modelagem.

5) É possível combinar Generalização Poo com composição?

Sim. Uma abordagem madura frequentemente combina: hierarquias para contratos estáveis e composição para variações ortogonais. O ponto é manter responsabilidades bem delimitadas. Em geral, herança trata “é-um” (tipo semanticamente substituível) e composição trata “tem-um” (responsabilidades colaborando).

6) Existe uma regra de ouro para profundidade de herança?

Não há um número fixo universal. A regra prática é avaliar se a hierarquia permanece compreensível, com substituibilidade preservada e sem efeitos colaterais frequentes em mudanças. Se a profundidade estiver dificultando manutenção, reavalie o desenho, não apenas a contagem de níveis.

7) Como documentar Generalização Poo para a equipe?

Registre: (1) intenção da classe base (qual conceito do domínio representa), (2) quais invariantes precisa manter, (3) como subtipos devem estender/overriding e (4) quais testes validam o contrato. Isso reduz interpretação divergente entre desenvolvedores e acelera integração de novos membros no time.

Conclusão: quando Generalização Poo melhora de verdade o projeto

Generalização Poo é uma estratégia poderosa para organizar classes e comportamentos de modo reutilizável e sustentável—desde que a abstração seja semântica, o contrato seja claro e os subtipos preservem substituibilidade. Quando você trata generalização como decisão de modelagem (e não como atalho), tende a obter sistemas mais fáceis de evoluir, com manutenção previsível e testes mais confiáveis.

Se no seu contexto houver exigências adicionais (por exemplo, idioma de implementação, padrões da empresa, ou limitações do framework), elas devem orientar a forma de aplicar a generalização. Caso você queira, posso adaptar este guia ao seu caso com uma hierarquia de exemplo e critérios de validação por testes—mantendo o foco em invariantes, substituição e redução real de duplicação.