Generalização Poo: guia técnico e práticas recomendadas

1) O que você precisa entender sobre Generalização Poo, logo de início

Generalização Poo é um mecanismo central em programação orientada a objetos (POO) para organizar responsabilidades: você cria abstrações que representam o “comum” entre entidades e, a partir delas, define comportamentos mais específicos. Em termos práticos, isso ajuda a manter o sistema coerente, diminuir repetição e facilitar evolução—desde que seja aplicado com critério, evitando hierarquias frágeis, acoplamento desnecessário e “conveniências” que não correspondem ao domínio.

Do ponto de vista de engenharia de software, a questão não é apenas “ter herança”, mas sim modelar corretamente o domínio: a generalização deve refletir uma relação conceitual legítima (por exemplo, “um tipo específico é um caso do tipo geral”), e não apenas uma forma de reaproveitar código ou “centralizar” métodos por comodidade. Quando a generalização está alinhada ao domínio, a estrutura tende a sobreviver ao crescimento do sistema. Quando está desalinhada, tende a quebrar com a evolução natural do produto.

Um jeito útil de começar a pensar é: generalizar é assumir compromissos. Ao criar um tipo geral, você promete que qualquer instância de um tipo especial continuará válida quando tratada pelo tipo geral. Essa promessa tem implicações para invariantes, pré-condições e pós-condições — mesmo que sua linguagem não as force formalmente. Em outras palavras: generalização é menos sobre “como o código é organizado” e mais sobre “o que o sistema garante”.

Isso também explica por que, em projetos maduros, generalização costuma ser tratada como uma decisão arquitetural. Você não “liga herança” sem avaliar impacto: mudanças no tipo base podem afetar toda a árvore e, em geral, impactam mais do que mudanças locais. Logo, entender o conceito cedo é essencial para evitar custos futuros.

2) Conceito e por que a Generalização Poo impacta qualidade

Em Generalização Poo, o objetivo é representar características compartilhadas e comportamentos comuns em uma estrutura mais geral (classes base/abstrações) e deixar variações para especializações (subclasses/implementações). Isso se conecta diretamente a princípios de design como:

• Coesão: regras e dados relacionados devem ficar juntos, evitando espalhar lógica em vários lugares e reduzindo o número de pontos onde você precisa alterar o comportamento para corrigir ou evoluir uma regra.
• Baixo acoplamento: componentes devem depender de abstrações estáveis, não de detalhes voláteis. Um tipo geral estável pode ser uma boa fronteira, mas um tipo geral instável vira fonte de acoplamento.
• Substituição segura: instâncias de especializações devem poder ser tratadas pelo tipo geral sem quebrar invariantes e sem provocar efeitos colaterais inesperados do ponto de vista do modelo.

Quando feito corretamente, esse padrão melhora a manutenibilidade e aumenta a previsibilidade do comportamento do sistema em mudanças incrementais. O motivo é que a generalização transforma repetição em estrutura e estrutura em significado: em vez de ver cópias, você enxerga a lógica como parte de um contrato. Isso reduz bugs recorrentes (porque você altera a lógica uma vez) e reduz a chance de divergência entre comportamentos que eram “quase iguais”.

Quando feito de forma errada, tende a criar “arquiteturas em camadas de herança” difíceis de entender e testar. Esse é um fenômeno comum: a hierarquia cresce, os overrides aumentam, e o sistema passa a funcionar como um conjunto de exceções e casos especiais distribuídos pela árvore — muitas vezes, sem um contrato claro que explique por que cada especialização é um caso válido do tipo geral.

Para tornar isso mais concreto, pense na seguinte situação: você cria uma classe base Pagamento com um método calcularValor() e, depois, percebe que alguns pagamentos não seguem exatamente a regra. Você acaba adicionando condições “se for isso” dentro do tipo geral ou criando muitas subclasses com overrides para tratar exceções. Em qualquer dos caminhos, a qualidade sofre: ou você infla o tipo base com detalhes, ou você cria uma hierarquia que precisa de conhecimento implícito para funcionar corretamente.

Uma boa generalização, por outro lado, costuma manter o tipo base com responsabilidades estáveis. Ele sabe o que é comum e o que é garantido. Ele não vira um “depósito de exceções”.

Além disso, a generalização influencia diretamente:

• Testabilidade: quando há um contrato claro e invariantes consistentes, é possível escrever testes por comportamento de forma mais previsível.
• Leitura do código: quando a hierarquia representa um modelo mental coerente, o código “conta uma história” ao leitor.
• Evolução: você consegue adicionar novas especializações sem reescrever o que já é comum, desde que o tipo base não mude com frequência e que seu contrato continue válido.

3) Generalização Poo versus outras ferramentas: o que confundir costuma custar caro

Uma fonte comum de problemas é tratar Generalização Poo como sinônimo de qualquer estrutura reutilizável. Porém, em projetos reais, herança/generalização pode ser pior do que alternativas como composição, interfaces e delegação.

Em geral, considere:

• Herança/generalização: faz sentido quando existe relação “é-um” (e a especialização preserva as garantias do tipo geral). O ponto-chave é a preservação de invariantes e a substituição segura — não apenas a semelhança de estrutura.
• Composição: faz sentido quando o sistema precisa de “tem-um” comportamento modular, mas sem vínculo forte de herança. A composição permite trocar peças sem comprometer o contrato de um tipo base.
• Interfaces: são úteis quando você quer definir contrato sem impor detalhes de implementação. Em muitos casos, é o caminho para estabilizar a dependência: você depende do “que” o objeto faz, não do “como” ele faz.

O que confunde é que, visualmente, muitos projetos parecem “reutilizar” com herança. Mas a reutilização real deve ser conceitual. Se você está criando uma hierarquia apenas porque existem métodos parecidos (ou porque “deveria estar junto”), pode estar construindo um acoplamento escondido.

Em termos de custo, há sinais de alerta práticos:

• Você frequentemente precisa modificar o tipo base para acomodar casos que “não cabem nele”.
• Subclasses precisam “desfazer” comportamento herdado que não é verdade para elas.
• O desenvolvedor que lê uma classe filha precisa consultar a classe base e compreender uma série de regras internas para entender o resultado final.
• Mudar um detalhe no tipo base exige revisão/correção em várias subclasses (cascata de manutenção).

Se isso acontece, muitas vezes a causa não é “falta de testes”, mas sim uma modelagem ruim: generalização aplicada onde seria necessária composição ou um contrato via interface.

4) Como estruturar uma hierarquia baseada em Generalização Poo (visão de especialista)

Como referência de práticas consolidadas em engenharia de software, a abordagem costuma seguir uma lógica de modelagem e validação:

1. Identifique responsabilidades compartilhadas: observe quais operações e invariantes realmente se repetem entre entidades e, principalmente, se repetem por um motivo conceitual. Não basta aparecerem nos mesmos lugares: elas precisam ser o mesmo tipo de regra no domínio.
2. Defina o contrato do tipo geral: determine quais métodos/atributos são essenciais e quais devem ficar escondidos. O contrato envolve o que é permitido, o que é proibido e as expectativas de comportamento em diferentes cenários.
3. Escolha o nível de abstração: o tipo geral deve ser suficientemente amplo para reutilização, mas não tão genérico que perca significado. Um tipo “genérico demais” vira um amontoado de “casos especiais” e “exceções”.
4. Imponha invariantes com clareza: garanta que o comportamento padrão do tipo geral seja válido para todas as especializações. Se você não consegue explicar as invariantes em linguagem natural, a hierarquia provavelmente não está estável.
5. Limite a profundidade da herança: hierarquias muito profundas dificultam rastreamento mental, aumentam a chance de overrides conflitantes e complicam a testabilidade.
6. Prefira polimorfismo por contratos estáveis: especializações devem trocar comportamento sem romper o que o tipo geral promete. Quando a estabilidade do contrato é fraca, o polimorfismo vira um risco.

Esse roteiro ajuda a transformar Generalização Poo de um “recurso de linguagem” em uma decisão arquitetural com impacto positivo. Um especialista não se limita a “encaixar classes”; ele valida se a hierarquia representa o domínio e se as garantias fazem sentido para qualquer instância.

Outra técnica associada é iterar o design em ciclos curtos: criar um protótipo mínimo da hierarquia, escrever testes por comportamento (mesmo que simples) e só então expandir a árvore. Isso evita descobrir tarde demais que o tipo geral não comporta as variações.

Também é comum que especialistas usem “marcadores” de invariantes. Por exemplo, em muitos domínios, você pode enunciar: “toda instância de Pagamento deve sempre ter um valor não-negativo e um status coerente”. Esses enunciados guiam a implementação do tipo base e tornam visível quando uma subclasse tenta escapar do modelo.

5) Critérios objetivos para decidir “generalizar ou não generalizar”

Ao aplicar Generalização Poo, avalie as seguintes condições:

• Há invariantes comuns? Se não houver garantias consistentes no tipo geral, a herança pode ser apenas uma forma de copiar estrutura. Nesse caso, “parece herança” mas não é generalização real.
• O comportamento comum é realmente comum? Se “comum” for só nome parecido ou uma implementação que coincide por acaso, pode ser melhor usar composição, interfaces ou até funções/estratégias separadas.
• As especializações substituem o tipo geral? A lógica do sistema deve continuar correta ao trocar a instância por uma especialização. Se a troca quebra invariantes, a relação “é-um” não está sendo respeitada.
• O custo de mudança é controlável? Se toda mudança no tipo geral exige ajustes em toda a árvore, o design está instável. Esse custo é o “termômetro” de estabilidade do contrato.

Esses critérios tornam a decisão menos subjetiva e reduzem retrabalho. Ainda assim, podem existir nuances práticas. Por exemplo, você pode generalizar inicialmente para refletir um entendimento parcial do domínio, mas precisa reconhecer que o contrato ainda pode mudar. O que protege o sistema, nesse caso, são testes e uma arquitetura que permita refatorar cedo se a hipótese de generalização estiver errada.

Um critério prático adicional, muito usado em revisão de design, é: quantas vezes você precisará pedir desculpas no tipo base? Se, para acomodar variações inevitáveis, o tipo base vira um “motor de regras internas” que depende do tipo real, isso é um indício forte de que a generalização não está bem modelada. Nesses cenários, padrões como estratégia, estado, visitor (quando faz sentido) ou composição com delegação costumam ser melhores.

6) Exemplos típicos de Generalização Poo (sem dependência de linguagem)

Embora a implementação varie entre linguagens, o raciocínio é semelhante:

• Modelo de domínio: “Veículo” como tipo geral; “Carro” e “Moto” como especializações. Aqui, o ponto é garantir que “todo veículo” compartilha invariantes (ex.: capacidade de se mover de acordo com regras do domínio) e que as especializações não contradizem o modelo.
• Camadas de serviço: “Repositório” como abstração; especializações para diferentes fontes (ex.: bancos/arquivos). Nesse caso, o contrato do “repositório” precisa ser bem definido: operações suportadas, semântica de consistência e comportamento esperado em erros.
• Processadores: “Processador” define um fluxo padrão; subclasses implementam etapas específicas. Aqui, é comum haver uma sequência de passos (pipeline). O cuidado é garantir que o fluxo “padrão” seja realmente universal e não dependa de exceções internas por tipo.

O ponto é que o tipo geral não deve ser um depósito de exceções. Ele deve representar um núcleo conceitual real—isso é o que sustenta Generalização Poo em longo prazo. Se você perceber que o tipo geral só existe porque “vamos colocar o método comum aqui”, isso pode ser apenas refatoração sem modelo. Às vezes, é uma etapa necessária; em outros casos, vira um design frágil.

Um exemplo “de aprendizagem” (que aparece muito) é quando alguém cria Pagamento e depois cria subclasses PagamentoComCartao, PagamentoComBoleto, PagamentoComPix. Se todas compartilham invariantes (ex.: todo pagamento tem valor, data, status), a generalização faz sentido. Se algumas têm invariantes diferentes (ex.: regras de expiração ou exigência de campos), você precisa decidir: ou essas diferenças ficam dentro do contrato com mecanismos adequados, ou o modelo generalizado precisa ser reavaliado.

7) Riscos comuns ao aplicar Generalização Poo

Mesmo quando há boas intenções, surgem riscos previsíveis:

• Fragilidade da base: mudanças no tipo geral quebram especializações. Isso costuma ocorrer quando o contrato não é estável, quando o tipo base “cresce” sem controle ou quando subclasses dependem de detalhes internos não documentados.
• Hierarquias “milagrosas”: o código funciona por acidente, mas não por contrato. Isso costuma acontecer quando o tipo base tem lógica condicional baseada em estado interno que não é garantido por invariantes explícitas.
• Override desnecessário: excesso de sobrescritas cria confusão sobre qual lógica realmente roda. Um sistema com muitos overrides frequentemente se torna difícil de prever e testar.
• Acoplamento indireto: detalhes do tipo geral “vazam” para o restante do sistema. Isso acontece quando outras partes do sistema precisam conhecer particularidades da hierarquia.

Em geral, quanto mais a hierarquia depende de suposições internas, maior a chance de regressões. Por isso, a generalização deve ser acompanhada de testes e revisão de invariantes. Mas testes não substituem boa modelagem: eles apenas reduzem o risco de falhas silenciosas.

Existe também um risco menos óbvio: generalização prematura. Às vezes, duas entidades parecem compartilhar algo agora, mas no curto prazo a semelhança pode ser superficial. Generalizar cedo pode congelar decisões do design que deveriam ser atrasadas. Uma forma de mitigar é: criar abstrações mínimas e contratos pequenos, e evitar antecipar variações futuras como se já fossem verdade.

Outro risco recorrente é a subclasse que não é substituível. Em termos conceituais, é quando a subclasse viola expectativas do tipo base. Isso pode ocorrer por:

• mudança de comportamento em relação a pré-condições e pós-condições;
• uso de exceções para sinalizar violações que deveriam ser tratadas no modelo;
• alteração de invariantes (ex.: permitir estado inválido que o tipo base assumia como impossível).

Quando isso acontece, os testes geralmente falham de forma “misteriosa” em partes do sistema que dependiam do tipo base — porque a substituição segura não é garantida.

8) Boas práticas que preservam a intenção da Generalização Poo

Recomendações práticas (independentes de linguagem) que tendem a melhorar a qualidade:

• Evite herança para reutilizar código “apenas por conveniência”: use abstração para responsabilidades, não para copiar detalhes. Se você só quer reutilizar implementação e não há invariantes e contrato compartilhados, prefira composição ou extração de helpers.
• Documente o contrato: invariantes, pré-condições e expectativas de comportamento do tipo geral. Uma regra simples: o contrato deve ser mais fácil de entender do que a implementação.
• Use testes por comportamento: valide o que o sistema promete, não apenas o que a implementação faz hoje. Para o tipo geral, testes de substituição (substituir uma instância por outra especialização) ajudam a revelar violações de contrato.
• Refatore com cuidado: altere primeiro o modelo mental; depois, ajuste a estrutura. Uma mudança “cega” na hierarquia pode quebrar suposições invisíveis.
• Faça revisões de design: especialmente quando a árvore crescer ou a profundidade aumentar. Revisões ajudam a detectar hierarquia inflada e contratos instáveis.

Além dessas práticas, há algumas “políticas” que funcionam bem na prática:

• Minimize o que é override: se um método do tipo base raramente precisa ser sobrescrito, evite torná-lo “facilmente sobrescrevível” sem necessidade.
• Prefira métodos “template” com controle do fluxo quando houver sequência invariável e variações bem definidas. Mas cuidado: templates mal desenhados podem virar acoplamento ao esqueleto.
• Evite estado compartilhado mutável perigoso no tipo base. Estado mutável compartilhado costuma causar dependências indiretas e efeitos colaterais difíceis de rastrear.

Outra boa prática é “ensaiar” a hierarquia com exemplos. Antes de implementar, descreva situações concretas: “um Carro faz isso e aquilo”; “uma Moto também, mas com variação X”. Se você não consegue explicar, a generalização pode estar grande demais ou mal recortada.

9) Quando a Generalização Poo deve ser complementada por outros padrões

Em muitos sistemas, a generalização sozinha não resolve todo o problema. Você pode precisar complementar com:

• Interfaces/contratos para isolar responsabilidades variáveis. Quando a variação não é natural como “é-um”, muitas vezes é “faz-o” (contrato) e não “é-um” (hierarquia).
• Composição quando o comportamento é plugável e não uma consequência natural da relação “é-um”. Em vez de criar subclasses para trocar partes do algoritmo, você pode compor com objetos que implementam estratégias.
• Princípio de inversão de dependência para reduzir acoplamento entre módulos. O tipo geral pode ser uma boa abstração, mas a dependência deve ser na direção certa: módulos de alto nível dependem de contratos estáveis.
• Estratégias/técnicas de variação quando o algoritmo muda sem que o modelo “mude de tipo”. Isso é comum: o tipo do objeto é o mesmo, mas a forma de calcular/validar/transformar varia por contexto.

Assim, a Generalização Poo permanece como eixo conceitual, enquanto a variabilidade fica sob controle por contratos e composição. Na prática, essa combinação é frequente: você tem uma pequena hierarquia para modelar “é-um” e, dentro dela, usa composição para variações de comportamento que não são estáveis como herança.

Um exemplo típico: você tem um domínio de “Pedido”. Existem especializações de pedido (por exemplo, “Pedido Online” e “Pedido Loja”), mas o cálculo de frete pode variar por transportadora. Em vez de criar subclasses para cada combinação possível, você pode generalizar a entidade e compor um componente de cálculo de frete baseado em contrato.

Esse tipo de desenho reduz explosão combinatória na hierarquia (um problema real quando o número de variações cresce rapidamente). Em hierarquias puras, o número de subclasses pode crescer como produto das variações, enquanto composição permite tratar variações como peças intercambiáveis.

10) Requisitos, condições e guia passo a passo (tabela comparativa + execução)

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

1. Mapeie o domínio: descreva as entidades e suas relações. Verifique se há uma relação “é-um” e se essa relação é verdadeira do ponto de vista do modelo (não apenas do código).
2. Liste operações e invariantes comuns: se não houver invariantes, talvez não seja generalização real. Invariantes podem ser: valores permitidos, comportamentos obrigatórios, restrições de estado, regras de consistência.
3. Crie o tipo geral com contrato explícito: defina comportamento padrão e limites. Idealmente, o contrato deve dizer o que acontece em casos normais e em casos de erro/violação (como o sistema responde).
4. Implemente especializações com responsabilidade clara: cada subclasse deve cumprir o contrato e alterar apenas o que faz sentido. Se o tipo base exige algo que a subclasse não pode garantir, isso é um sinal.
5. Valide com testes de comportamento: teste cenários que provam substituição e coerência do comportamento. Testes de substituição são especialmente valiosos para detectar violações do contrato do tipo base.
6. Revise hierarquia e profundidade: se a árvore crescer demais, considere refatoração para composição/contratos. Não espere a hierarquia virar “spaghetti”; corrija antes.
7. Documente decisões de design: explique por que a generalização é apropriada naquele caso e quais invariantes sustentam a relação. Essa documentação serve para manutenção futura e para onboarding de novos desenvolvedores.

Condições/termos de aceitação (para manter qualidade)

• O tipo geral deve manter invariantes consistentes que fazem sentido para todas as especializações.
• Especializações não podem violar expectativas fundamentais do contrato (mesmo que “funcione” no momento).
• O número de overrides relevantes deve ser justificável por variação real de comportamento, e não por falta de modelagem.
• O design deve suportar mudanças incrementais sem cascata descontrolada. Se toda mudança no contrato base gera impacto grande, reavalie o recorte do tipo geral.

Um ponto adicional que ajuda muito na aceitação é a avaliação do “custo cognitivo”: se um desenvolvedor precisa de múltiplas páginas para entender a lógica total de uma instância, provavelmente a hierarquia está criando dependências demais. Hierarquias bem feitas ainda exigem atenção, mas tendem a reduzir o esforço mental porque o contrato organiza a compreensão.

Se você estiver executando o guia em um time, uma prática útil é criar uma checklist de revisão de pull request específica para generalização:

• Qual é a relação “é-um” que justifica a herança?
• Quais invariantes são garantidas no tipo base?
• Quais métodos precisam ser sobrescritos e por quê?
• Que testes provam substituição e consistência?
• O contrato do tipo base está explícito e documentado?

Esse tipo de checklist aumenta a consistência do time e reduz decisões ad hoc.

11) FAQs sobre Generalização Poo

O que é Generalização Poo em poucas palavras?

É a prática de modelar uma abstração geral (tipo base/parent) que concentra responsabilidades comuns, permitindo que tipos específicos (filhos/subclasses) especializem comportamentos sem perder coerência e sem violar as promessas do tipo geral.

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

Não necessariamente. O termo remete a generalizar conceitos; em programação, isso costuma ser expresso por herança, mas também pode ser alcançado por contratos (interfaces), composição e delegação, dependendo da linguagem e do design. Em geral, “generalização” é o raciocínio; “herança” é uma possível ferramenta para implementá-lo.

Quais são os sinais de que a hierarquia está errada?

Indícios comuns incluem: tipo geral com muitas exceções, necessidade de overrides “vazios” ou “trapaceiros”, cascata de mudanças ao alterar a classe base e dificuldade de explicar, em linguagem natural, por que cada subclasse é um caso do tipo geral. Outros sinais são:

• subclasses que precisam redefinir comportamento para manter invariantes que o tipo base assumia;
• métodos do tipo base com lógica condicional baseada no tipo real (por exemplo, “se for X então…”);
• uso excessivo de “protected” ou variáveis internas acessíveis demais, indicando vazamento de detalhes.

Generalização Poo pode piorar performance?

O custo de chamadas polimórficas e estruturas de OO existe, mas geralmente não é a causa principal de problemas. Em sistemas reais, o risco maior costuma ser manutenibilidade, complexidade e previsibilidade do design. Se performance for crítica, perfis de execução e testes de carga são recomendados para embasar decisões. Ainda assim, vale observar:

• em geral, o overhead de polimorfismo costuma ser pequeno comparado a I/O, rede e banco;
• o que costuma causar impacto real é a estrutura do sistema criar trabalho extra (por exemplo, cascatas de chamadas por hierarquia mal desenhada).

Como lidar com “comportamentos quase iguais” entre especializações?

Verifique se existe um contrato comum real. Se for apenas similaridade superficial, considere composição, estratégia de variação ou pequenos helpers para evitar que o tipo geral se torne inflado. Uma forma de avaliar é perguntar:

• “As diferenças são variações de comportamento (estratégias) ou variações do modelo (especializações)?”
• “O que é garantido no tipo geral se eu trocar por qualquer especialização?”

Se a diferença for essencialmente um “como fazer”, não “o que ser”, composição/estratégia tende a ser melhor.

Qual a melhor forma de documentar a generalização?

Declare invariantes e expectativas do contrato do tipo geral, descreva pré e pós-condições quando aplicável e registre exemplos de substituição segura (quando uma instância específica pode ser usada como o tipo geral). Documentação útil costuma incluir:

• o que toda instância do tipo geral pode assumir (estado e valores válidos);
• o que o tipo geral promete executar (comportamento) e em que condições falha;
• as regras que especializações devem respeitar (por exemplo, “não alterar X” ou “deve sempre produzir Y”).

Existe relação entre Generalização Poo e princípios de design?

Sim. A generalização se conecta a princípios como coesão, baixo acoplamento, substituição comportamental (conceitualmente) e clareza de responsabilidades—especialmente quando decisões são feitas para preservar contratos e facilitar evolução. Além disso, há ligação com práticas de engenharia como:

• definição de limites (boundaries) entre módulos;
• controle de dependências;
• modelagem alinhada ao domínio;
• refatoração guiada por testes.

12) Conclusão: Generalização Poo como decisão arquitetural

Ao aplicar Generalização Poo, você transforma repetição em estrutura e cria um caminho claro para evolução do software. Contudo, o ganho só se sustenta quando a generalização representa um conceito legítimo do domínio, preserva invariantes, mantém contratos explícitos e limita a complexidade da hierarquia. Assim, a orientação a objetos deixa de ser apenas sintaxe e passa a ser uma ferramenta de qualidade: ela organiza responsabilidades de modo que o sistema continue compreensível conforme cresce.

Quando a generalização é bem feita, ela reduz o “trabalho mental” do time: fica mais fácil prever o comportamento, encontrar responsabilidades e alterar o sistema com confiança. Quando é mal feita, ela cria o oposto: dependências invisíveis, cascatas de mudança e bugs que só aparecem em combinações específicas de estados.

Próximo passo sugerido: revise seus modelos atuais e identifique se as “classes base” realmente capturam responsabilidades estáveis. Se estiverem apenas reunindo código por conveniência, pode ser o momento de reestruturar para contratos e composição—preservando a intenção da Generalização Poo onde ela realmente agrega valor.

Fontes e referências conceituais (para embasar práticas)

Para fundamentar a discussão de design em OO e princípios correlatos, recomenda-se consultar: Clean Code (Robert C. Martin), Design Patterns (Erich Gamma et al.), além de diretrizes e práticas em engenharia de software como as dos Martin Fowler (artigos sobre refatoração e design) e estudos clássicos sobre polimorfismo, coesão e acoplamento em arquitetura de software. Também é útil buscar materiais sobre:

• refatoração orientada a testes e contratos;
• princípios de substituição comportamental e modelagem por invariantes;
• comparação entre herança, composição, delegação e estratégias de variação.