Generalização em POO: guia técnico para decisões seguras

Generalização Poo: por que ela define a qualidade do seu desenho

Ao projetar sistemas em Programação Orientada a Objetos (POO), a Generalização Poo é uma das decisões mais determinantes: ela orienta como você modela classes, compartilha responsabilidades e estabelece limites entre “o que é comum” e “o que muda”. Quando feita com critério, a generalização reduz retrabalho, melhora consistência e facilita evolução. Quando feita no impulso—ou de forma rígida—pode criar hierarquias frágeis, acoplamento excessivo e manutenção cara.

Neste guia, você terá uma visão objetiva e prática, com foco em análise técnica. A ideia central é simples: generalizar é buscar semelhanças reais no comportamento e no contrato (interface), não apenas “semelhanças visuais” entre atributos.

1) O que significa “Generalização Poo” na prática

Em POO, generalização geralmente se manifesta por meio de:

• Herança (ex.: base class e subclasses);
• Interfaces e contratos (quando a intenção é “comportamento”, não estrutura);
• Abstração (ex.: classes abstratas, métodos polimórficos e templates de comportamento);
• Polimorfismo (mudar a execução mantendo o mesmo contrato).

O ponto-chave é que a generalização deve representar um relacionamento semântico: a subclasse deve ser uma forma válida da superclasse, respeitando invariantes e condições esperadas. Em outras palavras, não é “duas classes parecidas”; é “uma classe pode ser tratada como outra sem que a lógica do sistema quebre”.

Para tornar isso mais concreto, pense na diferença entre:

• Semelhança estrutural: “as duas classes têm os mesmos atributos, então podemos extrair uma base com esses atributos”;
• Semelhança comportamental: “as duas classes obedecem ao mesmo conjunto de regras e fornecem os mesmos resultados sob as mesmas condições”;
• Semelhança de contrato: “o consumidor que usa o tipo superclasse não precisa saber qual subtipo está por trás para estar correto”.

Qualidade do desenho tende a aumentar quando você aumenta o peso de contrato e comportamento na sua decisão, em vez de depender apenas de forma.

Em termos de “desenho”, a generalização é como o seu sistema “aprende” a organizar conhecimento. Se você generaliza direito, o restante do sistema passa a falar a mesma língua: conceitos diferentes compartilham garantias comuns. Se você generaliza errado, a hierarquia vira uma coleção de exceções e gambiarras, obrigando o resto do código a compensar as ambiguidades que a modelagem introduziu.

2) Critérios de decisão: quando generalizar (e quando não)

Como especialista em engenharia de software, eu costumo avaliar generalização em camadas: contrato, comportamento e evolução. Abaixo vai um conjunto de critérios que tende a reduzir problemas recorrentes.

2.1) Generalize quando houver contrato comum e invariantes claros

Se diferentes entidades compartilham regras estáveis—por exemplo, um mesmo conjunto de garantias de entrada/saída, validações e efeitos colaterais—há boa chance de existir uma generalização que faça sentido.

Exemplo conceitual: se “formas” diferentes precisam fornecer área e perímetro, o contrato comum pode ser uma interface ou classe abstrata. O valor do método muda, mas a assinatura e o significado permanecem. O consumidor pode pedir “área” e “perímetro” sem precisar de ifs do tipo concreto.

Agora observe um ponto sutil: um contrato bem definido não é só “ter o método”. Ele inclui:

• Pré-condições: quais são as condições para chamar um método com segurança;
• Pós-condições: o que deve valer ao retornar;
• Invariantes do objeto: propriedades que devem permanecer verdadeiras durante o ciclo de vida;
• Efeitos colaterais: o que muda no estado, quais eventos são disparados, quais recursos são alocados;
• Regras de erro: quando lançar exceções, quais mensagens fazem sentido, e quais estados resultam.

Quando esses itens são genuinamente comuns, você ganha um ponto forte a favor da generalização. Quando não são comuns—mesmo que “funcionem por acaso”—a base vira terreno fértil para bugs silenciosos.

Na prática, um teste que ajuda: se você escrever uma função genérica que recebe o tipo superclasse e executa o método polimórfico, ela continua correta para todos os subtipos? Se sim, você provavelmente tem uma generalização correta. Se a função precisa de lógica extra “por tipo”, o que você chamou de generalização pode não ser semanticamente sólido.

2.2) Evite generalizar quando a similaridade for superficial

Uma armadilha comum é perceber que duas classes têm campos parecidos e, por isso, “criar uma base” com esses campos. Isso costuma falhar porque:

• Os campos podem não ter a mesma semântica;
• As operações podem divergir em requisitos;
• O ciclo de evolução tende a divergir, gerando “buracos” na hierarquia (classes base virando depósito de exceções).

Essa situação aparece com frequência em domínios onde existem “conceitos” que parecem semelhantes na superfície, mas são diferentes na regra. Por exemplo:

• Dois tipos podem ter um campo status, mas o significado do status pode ser completamente diferente (por exemplo: “pendente de pagamento” vs “pendente de aprovação”), além de regras de transição distintas.
• Dois objetos podem ter um campo id, mas a origem (gerado pelo banco, gerado pelo usuário, importado de um sistema legado) pode implicar invariantes diferentes.
• Dois modelos podem compartilhar createdAt, mas o que isso representa (momento de persistência vs momento de evento do domínio) muda o contrato de leitura.

Quando a similaridade é superficial, você costuma acabar com:

• métodos na base que não fazem sentido para todos os subtipos;
• métodos obrigatórios que cada subtipo implementa de um jeito incompleto;
• ganchos (hooks) que viram “pontos de quebra” sempre que alguém adiciona um novo subtipo;
• if-else por tipo espalhado pelo sistema, tentando compensar a fragilidade da hierarquia.

Em geral, se a base “força” semânticas que não são compartilhadas, a hierarquia se torna um fardo. E, ironicamente, quanto mais “parecidas” parecem as classes, mais tentador é construir a herança cedo—antes de você entender o comportamento e as transições do domínio.

2.3) Cuidado com herança profunda e acoplamento implícito

Hierarquias longas podem induzir violações do princípio de substituição comportamental: subclasses deixam de ser substituíveis sem “pegadinhas” (efeitos colaterais, pré-condições mais fortes ou pós-condições diferentes). Isso raramente aparece na primeira semana, mas cobra juros ao longo do tempo.

O problema típico de herança profunda não é só o “número de níveis”. É o fato de que, com mais níveis, cresce a distância entre a intenção do contrato e o que de fato o objeto faz. Quando uma regra comum é implementada na superclasse, mas sua execução depende de detalhes de overrides abaixo na cadeia, você cria um acoplamento implícito: a base passa a depender do comportamento de subclasses, mesmo que isso não esteja explicitamente declarado.

Alguns sintomas arquiteturais de acoplamento implícito por herança:

• Você muda a superclasse e precisa “checar tudo” em subclasses, porque não sabe quais invariantes serão afetadas.
• Você sobrescreve métodos “só para ajustar um detalhe”, e esse ajuste impacta outros passos do algoritmo que dependiam do comportamento original.
• Há necessidade constante de documentar “não faça X na implementação do override” — ou seja, o contrato real vira texto informal.

Uma forma de combater isso é limitar profundidade e preferir generalizações que agrupem comportamento coeso em uma única camada. Além disso, quando o fluxo comum exige etapas específicas, padrões como Template Method podem ajudar, mas com disciplina: ganchos devem ser poucos, bem nomeados e com contratos claros.

3) Generalização vs. composição: visão de arquitetura

Embora o termo “Generalização Poo” aponte para herança, a arquitetura moderna frequentemente combina generalização com composição. Uma regra prática é esta:

• Generalize quando o relacionamento for “é-um” com semântica correta e substituibilidade;
• Prefira composição quando o relacionamento for “tem-um” ou quando o comportamento variar independentemente do tipo.

Essa abordagem reduz a rigidez: você troca componentes sem precisar reorganizar hierarquias inteiras.

Repare que “é-um” não é só um enunciado linguístico. Para ser válido, “é-um” precisa manter o contrato. Um carro é um veículo, mas um carro “não é” um pedestre. Se você fizer a modelagem errada (por exemplo, herdando de forma que “carro é pedestre”), a lógica do domínio entra em contradição.

Em muitos sistemas, composição resolve o problema de variar comportamento sem criar hierarquia profunda. Exemplos comuns:

• Estratégias de cálculo (ex.: impostos diferentes) podem ser componentes pluggáveis.
• Validações podem ser colecionadas por regras de domínio.
• Formatadores e serializadores geralmente são melhor modelados como componentes, não como subclasses de um “base de formatação” com dezenas de variações.

Quando você mistura generalização e composição, você deve pensar em “quem deve conhecer quem”. Generalização tende a organizar o conhecimento por tipo; composição organiza por capacidade (habilidade / comportamento delegado). Dependendo do domínio, uma abordagem melhora mais a evolução do software.

4) Boas práticas do “especialista”: como modelar hierarquias robustas

4.1) Use herança para compartilhar comportamento, não apenas estado

Estado (atributos) pode até ser compartilhado, mas o valor mais duradouro está em compartilhar comportamento coerente: validações, estratégias de cálculo, fluxo de execução e contratos polimórficos.

Quando o compartilhamento está apenas no “depósito de dados”, a hierarquia tende a ficar artificial.

Uma boa heurística: se a sua superclasse só existe para fornecer getters/setters e alguns campos protegidos, talvez ela não seja realmente uma generalização—pode ser só uma reorganização do código por conveniência. Isso costuma criar o que eu chamo de “herança decorativa”: parece arquitetura, mas não é arquitetura de comportamento.

Em contrapartida, quando a superclasse realmente descreve regras do domínio, a herança passa a ser uma ferramenta de consistência. Por exemplo, em vez de “todas as entidades têm id, createdAt e updatedAt”, você pode extrair uma camada de base para lidar com invariantes de ciclo de vida (como atualização de timestamps, auditoria, ou identificação imutável). Ainda assim, isso depende do domínio: em alguns sistemas, auditoria é um assunto transversal melhor resolvido com interceptores, middleware ou serviços, evitando que a hierarquia carregue preocupações ortogonais.

Em resumo: estado é detalhe; comportamento é semântica. Se você generaliza comportamento, você constrói entendimento. Se você generaliza apenas estado, você constrói dependência.

4.2) Proteja invariantes e respeite pré/pós-condições

Se a superclasse define invariantes (por exemplo, “o objeto deve sempre ter X válido”), a subclasse deve preservá-los. Métodos sobrescritos que violam invariantes criam bugs difíceis de rastrear e tornam o polimorfismo perigoso.

O princípio aqui é que o “contrato” deve ser obedecido por todos os subtipos. Na prática, isso significa evitar:

• Pré-condições mais fortes no override (o método passa a exigir mais do que a superclasse exigia);
• Pós-condições mais fracas (o método retorna algo menos garantido);
• Alterações de invariantes (o objeto pode ficar em estado inválido após chamar a operação);
• Efeitos colaterais não documentados (o consumidor não esperava que aquilo acontecesse).

Uma situação real que frequentemente ocorre: uma classe base valida dados e garante “o objeto está sempre em estado consistente”. A subclasse sobrescreve um método de transformação que deveria manter essa consistência, mas por algum motivo deixa a entidade em um estado intermediário durante o processo (por exemplo, atualiza campos em sequência e pode ser observado por outro componente). Isso quebra invariantes de forma “intermitente”, gerando bugs que parecem condições de corrida ou falhas raras.

Se a sua linguagem suporta, use imutabilidade parcial, invariantes verificadas no construtor, e encapsule estado para reduzir a chance de “estado temporário exposto”. Se não suporta, imponha invariantes com validação consistente e evite “setters” que permitem estados invalidáveis.

4.3) Prefira interfaces para contratos amplos e classes abstratas para fluxos comuns

• Interfaces: ótimas para definir o que um componente “faz”, sem impor como ele armazena dados;
• Classes abstratas: úteis quando existe fluxo parcialmente comum (por exemplo, um “template method” que chama ganchos).

Essa distinção é muito importante para qualidade: interfaces limitam o que o sistema precisa saber; classes abstratas permitem reutilizar um algoritmo sem travar a implementação completa.

Quando usar interface?

• Quando múltiplas classes podem implementar o mesmo comportamento;
• Quando o contrato é mais importante do que a implementação compartilhada;
• Quando você quer desacoplar o consumidor da implementação.

Quando usar classe abstrata?

• Quando existe código reutilizável que é realmente comum (ex.: um algoritmo base, uma rotina de validação padrão, um fluxo de execução que chama passos variáveis);
• Quando você quer guiar subclasses com um padrão de extensão.

Porém, classe abstrata com muitos métodos “abertos” pode se tornar outra forma de fragilidade. Se a classe abstrata “espera” que subclasses implementem uma quantidade grande de detalhes, você perde o benefício do encapsulamento do comportamento comum: vira um quebra-cabeça em que ninguém tem certeza de quais passos são obrigatórios e quais são opcionais.

4.4) Evite métodos “genéricos” demais que viram correções na subclasse

Se a superclasse precisa de muitos métodos “genéricos” que as subclasses reimplementam o tempo todo, provavelmente você generalizou o lugar errado. Talvez o contrato correto seja menor (mais específico), ou talvez falte extrair colaboradores via composição.

Esse é um sinal bem claro: “a base não é usada como base; ela é usada como checklist”. Quando isso ocorre, você vê coisas como:

• override de quase tudo em cada subtipo;
• métodos base com implementações vazias ou com exceções do tipo “não implementado”;
• métodos base que têm comportamento incompleto porque assumem detalhes que só estarão disponíveis em subclasses.

Nesse cenário, uma alternativa comum é quebrar o contrato em partes menores (interfaces pequenas, responsabilidades específicas) e usar composição para montar comportamentos. Outra alternativa é tornar a superclasse mais “estreita” em escopo: compartilhar apenas o que é verdadeiramente comum e estável.

Uma pergunta de design que ajuda: “se eu remover esse método da base, o que quebra?” Se a resposta é “quase nada”, então talvez esse método não devesse estar na base. Se a resposta é “tudo”, então provavelmente o método é mesmo parte do contrato comum. É um filtro prático para reduzir classes base inchadas.

5) Relação com manutenção, testes e evolução

A Generalização Poo impacta diretamente:

• Testabilidade: com contratos claros, testes podem ser compartilhados por meio de fixtures e testes base (quando apropriado);
• Extensibilidade: novas subclasses entram com menor risco se respeitarem o contrato;
• Leiturabilidade: uma boa hierarquia comunica intenção;
• Manutenção: mudanças localizadas são mais fáceis quando o comportamento comum está bem isolado.

Vamos aprofundar cada um desses pontos para ficar mais tangível.

5.1) Testabilidade: testes de contrato e testes de substituição

Quando você generaliza corretamente, você consegue escrever testes em duas camadas:

• Testes do contrato: verificam invariantes, pré/pós-condições e comportamento esperado de forma genérica (por exemplo, “qualquer implementação de Pagamento deve gerar recibo com campos X e Y”).
• Testes específicos: verificam particularidades do subtipo (por exemplo, “Cartão debita assim, Pix aprova assincronamente”).

Isso melhora a velocidade e a segurança para evolução. Ao adicionar um novo subtipo, você roda os testes de contrato e sabe se a substituição está correta.

Quando a generalização é ruim, você tende a perder isso. Os testes ficam “colados” em implementações específicas, porque o contrato não é confiável. Pior: você tenta testar o que a base faz e descobre que a base depende de overrides que mudam entre subclasses, dificultando a criação de testes determinísticos.

Uma consequência prática: hierarquias frágeis elevam o custo de qualquer mudança, porque o medo de quebrar comportamento polimórfico torna a refatoração mais conservadora.

5.2) Extensibilidade: o custo de adicionar variantes

Um bom desenho com generalização correta reduz o custo cognitivo para adicionar um novo tipo. O time entende:

• qual contrato precisa ser respeitado;
• quais invariantes precisam ser preservadas;
• quais métodos devem produzir que efeitos;
• o que muda e o que permanece.

Em contrapartida, em hierarquias frágeis, adicionar um novo subtipo pode exigir:

• alterar a superclasse (porque não existe “hook” adequado);
• alterar código em outros lugares (porque faltou polimorfismo);
• criar ifs em consumidores (porque o contrato não cobre o caso);
• documentar exceções e “comportamentos especiais”.

Observe que tudo isso é um custo de arquitetura. Quando você modela por contrato e semântica, você evita que o sistema dependa de particularidades.

5.3) Leiturabilidade: a hierarquia como linguagem do domínio

Uma hierarquia bem feita comunica intenção. O nome das classes e interfaces não é enfeite: é a forma que o código descreve o domínio.

Se você cria uma classe base “Genérica” ou “BaseModel” sem semântica real, o código fica “opaco”. Se você cria classes com nomes que descrevem contratos (“Auditable”, “Verifiable”, “Calculable”, “SerializableStrategy”), a hierarquia passa a ser autoexplicativa.

Além disso, leiturabilidade também significa: quando você vê uma referência do tipo superclasse, o leitor consegue prever comportamento sem consultar implementações internas.

5.4) Manutenção: mudanças localizadas

O objetivo final de uma generalização sólida é que alterações aconteçam em lugares previsíveis. Se o comportamento comum está isolado em uma classe abstrata bem definida, você altera um método central e o restante se beneficia.

Se a generalização é ruim, mudanças comuns viram “mudanças em cascata”. Exemplo clássico: você adiciona um campo novo ao domínio e precisa atualizar várias subclasses e consumidores, porque a base não centralizou o contrato corretamente ou porque o estado compartilhado não tinha o mesmo significado em todas.

Em manutenção real, isso aparece como tempo gasto “caçando” efeitos e ajustando compilações e testes. A generalização correta reduz essa fricção.

6) Tabela comparativa de apoio: alternativas para generalizar

Uma leitura adicional da tabela: muitas vezes você escolhe uma abordagem não por preferência, mas por “tensão arquitetural”. Se a tensão é “muitas variações com mudanças independentes”, composição tende a vencer. Se a tensão é “um contrato comum com várias implementações”, interface tende a vencer. Se a tensão é “um algoritmo comum com pequenas partes variáveis”, template method e classe abstrata tendem a ser adequados. Se a tensão é “subtipos realmente são versões de um mesmo conceito”, herança pode ser inevitável e valiosa.

7) Guia passo a passo: aplicar Generalização Poo com segurança

1. Identifique o contrato: pergunte “o que essas entidades precisam garantir?” (entrada/saída, invariantes, efeitos).
2. Separe semelhança real de coincidência estrutural: campos parecidos não significam comportamento igual.
3. Defina a menor abstração útil: contratos menores tendem a reduzir fragilidade.
4. Escolha o mecanismo:
   • Interface para contrato;
   • Classe abstrata para fluxo comum;
   • Herança quando “é-um” for semântico;
   • Composição quando as partes evoluem separadamente.
5. Crie testes de contrato: valide que substituições funcionam (mesmo comportamento esperado sob variações).
6. Revise o impacto em herança profunda: se crescer rápido, reavalie com composição.
7. Documente pré/pós-condições: especialmente onde houver sobrescrita e polimorfismo.
8. Monitore “cheiros” de projeto: métodos sobrescritos repetidos, base class “inchada”, exceções frequentes e dependências implícitas.

Para tornar esse passo a passo ainda mais “operacional”, vale acrescentar algumas perguntas de revisão que você pode usar no PR (pull request) ou em uma sessão de design:

• Qual é o “contrato que permanece”? (o que o consumidor pode assumir).
• Quais invariantes realmente foram movidas para a superclasse? (e se elas são verdadeiras para todos os subtipos).
• Onde estão as pré-condições? (estão claramente documentadas e não ficam mais fortes no override?).
• Quem “paga” o custo de escolher o tipo? (idealmente, escolhe-se uma vez na borda do sistema; não se espalha ifs).
• O novo subtipo exige mudanças fora da hierarquia? (se sim, a generalização está vazando ou incompleta).

8) Fontes de referência (para embasar decisões, sem dados não verificados)

As recomendações aqui seguem princípios amplamente consolidados na engenharia de software e orientação a objetos, especialmente:

• Martin, Robert C. Agile Software Development: Principles, Patterns, and Practices e discussões associadas a princípios de design;
• Gamma, Helm, Johnson, Vlissides. Design Patterns (padrões e trade-offs de abstração e polimorfismo);
• Princípio de Substituição de Liskov, conforme discussões clássicas na literatura de fundamentos de linguagens e semântica de tipos.

Observação: este texto não depende de métricas proprietárias nem de estatísticas de performance que não estejam diretamente verificadas em relatórios públicos; o foco é arquitetural e conceitual.

Além disso, vale reconhecer que a prática moderna também evoluiu: muitos times adotam abordagens mais flexíveis para variação de comportamento (estratégias, composição por capacidades, injeção de dependências). Mesmo assim, a lógica por trás da generalização continua a mesma: contrato e substituibilidade são o núcleo.

9) Requisitos e condições para uma generalização bem-sucedida

• Substituibilidade: a subclasse deve funcionar onde a superclasse é esperada.
• Invariantes consistentes: regras fundamentais do objeto não podem ser quebradas por overrides.
• Baixa surpresa: métodos sobrescritos não devem alterar expectativas além do contratual.
• Reutilização com intenção: a generalização deve reduzir duplicação real de comportamento, não só de estrutura.
• Arquitetura evolutiva: o desenho deve suportar mudanças sem exigir refatorações extensas em cascata.

Para complementar essa lista, aqui vão condições adicionais que, na prática, definem se a generalização “aguenta” tempo:

• Coesão do que é comum: a classe base não deve agrupar regras que só se encontram por coincidência; o comum deve ter significado.
• Contrato explícito: o que é garantido deve ser fácil de entender (documentado, testado e, quando possível, reforçado por tipos).
• Estabilidade do contrato: se o contrato muda toda semana, a generalização pode estar prematura. Você pode precisar esperar amadurecimento ou separar em contratos menores.
• Controle de extensão: se a hierarquia exige muitos overrides, o sistema vira frágil. Extensões devem ser previsíveis e limitadas.
• Observabilidade das mudanças: mudanças na superclasse não devem criar efeitos inesperados. Idealmente, testes de substituição capturam isso.

10) FAQ — Perguntas frequentes sobre Generalização Poo

10.1) “Generalização Poo” é sempre herança?

Não. Embora herança seja um modo comum de generalizar, generalização também pode ser feita com interfaces, classes abstratas e contratos. O que importa é o relacionamento semântico e a substituibilidade, não apenas o mecanismo.

Uma forma de pensar: “generalização” é o raciocínio; “herança” é uma ferramenta. Se a ferramenta não expressa bem o raciocínio (por exemplo, porque o relacionamento não é “é-um”), então você deve trocar a ferramenta sem trocar o objetivo.

10.2) Posso usar generalização apenas por “parecer que tem a mesma cara”?

É uma má base para decisão. Se a semelhança é só estrutural (campos), a hierarquia tende a virar um repositório de exceções. Uma generalização sólida deriva de comportamento e contrato, com invariantes preservados.

Em linguagem mais simples: “parece igual” não é “é igual”. Em POO, o sistema “age” sobre objetos por meio de métodos e contratos. Se o comportamento não é compartilhado, não existe substituibilidade.

10.3) Qual o sinal de que a hierarquia está ficando frágil?

Alguns alertas recorrentes: subclasses com overrides cheios de exceções, base class com muitos métodos que nem sempre fazem sentido, necessidade frequente de “condicional por tipo”, e dificuldade de testar a substituição. Esses sintomas indicam que a abstração pode estar grande demais ou no lugar errado.

Além desses sinais, vale observar:

• Excesso de protected: quando o código fora da classe base precisa do que está protegido porque os contratos não estão bem resolvidos.
• Override de métodos “para corrigir”: a superclasse implementa um comportamento genérico que a subclasse desfaz.
• Documentação informal dentro do código: “não faça isso, senão quebra”. Isso é frequentemente um sintoma de contrato implícito e não respeitado.
• “Tin whistles” de design (mudanças pequenas que causam efeitos grandes): alteração em um método da base exige ajuste em várias subclasses.

10.4) Generalização ajuda a reduzir bugs?

Ela pode ajudar quando o contrato é bem definido e testado, pois reduz variações desnecessárias. Porém, se a substituibilidade for violada (por invariantes conflitantes), a generalização pode aumentar o risco de bugs difíceis de rastrear.

O raciocínio é o seguinte: com uma generalização correta, você centraliza comportamento comum e reduz divergência. Menos divergência significa menos chances de inconsistência. Com generalização errada, você centraliza a inconsistência e espalha efeitos por polimorfismo, criando bugs “em cascata”.

Então, o impacto em bugs não é “automático”. Ele depende da qualidade do contrato e da substituibilidade. A generalização funciona como uma amplificadora: amplifica o que está bem modelado e amplifica o que está errado.

10.5) Quando devo preferir composição em vez de generalização?

Quando a variação de comportamento não acompanha naturalmente o tipo (ou quando “cada caso muda de forma independente”). Composição tende a melhorar a flexibilidade e evitar hierarquias rígidas e profundas.

Exemplo comum: considere um objeto que precisa calcular preço. Você pode ter hierarquias por tipo de produto, mas o cálculo do preço pode depender de promoções, regras regionais e moeda. Esses fatores variam independentemente do “produto”. Aqui, composição por estratégias (PromotionStrategy, PricingPolicy) costuma organizar melhor do que herança em camadas por “produto + região + promoção”.

Outra situação: quando você quer evoluir componentes separadamente. Com composição, você substitui uma estratégia sem mexer no tipo principal, reduzindo acoplamento.

10.6) Há um “tamanho ideal” para a classe base?

Não existe um tamanho universal. O melhor indicador é se a classe base contém comportamento coerente e reutilizável que realmente representa o contrato comum. Se você percebe duplicação embaixo e condições no topo, é sinal de que a abstração perdeu o foco.

Como prática, você pode observar:

• Duplicação nas subclasses: se muitas subclasses implementam a mesma lógica, isso pode indicar que ainda falta extrair uma generalização (ou que o contrato é impreciso).
• Condições na base: se a base está cheia de ifs do tipo ou flags internas, talvez a base não represente uma abstração estável.
• Overrides frequentes: se a classe base declara muitos métodos abstratos e cada subtipo implementa uma porção diferente, a base pode estar ampla demais ou misturando responsabilidades.

Em geral, quando você precisa de “manual do desenvolvedor” para implementar subclasses corretamente, é sinal de que o tamanho/escopo pode estar errado.

10.7) Como documentar generalização para o time?

Documente o contrato: pré-condições, pós-condições, invariantes, e o que o método “significa”. Em ambientes de desenvolvimento colaborativo, também é útil registrar exemplos de como subclasses devem ser usadas e o que deve ser evitado.

Uma documentação eficaz não é apenas texto longo; é estrutura:

• Defina invariantes em termos objetivos (o que é sempre verdadeiro).
• Explique o significado de métodos (o que o método faz no domínio, e não só na mecânica).
• Se possível, use asserts e validações para reforçar invariantes em runtime.
• Inclua exemplos: “se chamar com X, deve produzir Y”.
• Liste o que não deve ser feito: “não sobrescreva este método” ou “ao sobrescrever, preserve invariantes A e B”.

Quando a documentação fica só na cabeça do autor, ela vira dívida técnica. Quando fica estruturada e testada, vira proteção para o time.

11) Considerações finais

A Generalização Poo é uma ferramenta de design poderosa, mas exige disciplina: o objetivo não é “organizar por semelhança”, e sim construir contratos estáveis que permitam polimorfismo seguro e evolução sustentável. Ao combinar análise de contrato, verificação de substituibilidade e escolha consciente entre herança, interfaces e composição, você cria sistemas mais previsíveis—e, com isso, mais fáceis de manter ao longo do tempo.

O ponto decisivo é entender que generalização não é estética. É semântica operacional. Ela existe para que o código que consome um tipo possa confiar em garantias reais, e para que o sistema como um todo não precise “adivinhar” exceções. Se a generalização respeita o contrato e preserva invariantes, ela vira um multiplicador positivo de qualidade. Se negligencia contrato e comportamento, ela vira um multiplicador de fragilidade.

Quando você internaliza isso, você começa a desenhar hierarquias que aguentam mudanças, suportam testes de substituição e facilitam a leitura do domínio. E, com o tempo, a equipe percebe: as melhores abstrações não são as que parecem mais gerais, e sim as que são mais corretas.