DEV Community: Yuri Peixinho

Processo de Teste

Yuri Peixinho — Sun, 04 Oct 2026 22:38:02 +0000

Introdução

O ISTQB não prescreve um processo único. Descreve atividades comuns, sem as quais o teste tem menos chance de atingir seus objetivos, e deixa a adaptação para o contexto. Os fatores que mais pesam:

modelos de ciclo de vida e metodologia do projeto;
níveis e tipos de testes considerado;
riscos de produto e de projeto;
domínio de negócio;
restrições operacionais: orçamento e recursos, prazos, complexidade, requisitos constrautias e regulatórios;
políticas e práticas da organização;
padrões internos e externos exigidos.

As atividades podem rodar em sequência ou de forma iterativa. Em qualquer projeto, podem se sobrepor, ser combinadas, rodar em paralelo ou ser omitidas. Em ágil, o teste acontece de forma contínua, dentro de cada iteração. O que fica estável é a pergunta que cada atividade responde.

O exemplo que atravessa o texto

Cenário hipotético. Um ERP financeiro SaaS vai gerar remessa CNAB 240 de pagamento a fornecedores para um segundo banco (Banco B). Seis semanas, três sprints, dois devs e dois testers. O banco exige homologação do arquivo e seu sandbox cobre só parte dos cenários. Risco central: arquivo rejeitado ou aceito em duplicidade.

As sete atividades

Atividade	Pergunta	Papel	Saída principal
Planejamento	Quais objetivos e qual abordagem, dentro das restrições?	Gestão	Plano de teste
Monitoramento e controle	Estamos no plano? O que corrigir?	Gestão	Relatórios de progresso
Análise	O que testar?	Teste	Condições de teste priorizadas
Modelagem	Como testar?	Teste	Casos de teste, requisitos de dados e de ambiente
Implementação	Está tudo pronto para rodar?	Teste	Procedimentos, suítes, cronograma, ambiente, dados
Execução	O resultado real bate com o esperado?	Teste	Status por teste, relatórios de defeitos
Conclusão	O que entregamos e aprendemos?	Gestão	Relatório de resumo, lições, testware arquivado

Os produtos de trabalho de todas as atividades formam o testware. Planejamento e monitoramento e controle atravessam o projeto inteiro: o plano é revisto a partir do que o monitoramento mostra.

1. Planejamento: quais objetivos, e qual abordagem?

Define os objetivos do teste e escolhe a abordagem que os atinge dentro das restrições e do contexto. A saída é o plano de teste. No mínimo ele aponta a base de teste (o material de onde os testes são derivados: requisitos, histórias, layouts, código) e os critérios de saída, também chamados de definição de feito. Um plano completo traz ainda escopo, premissas, partes interessadas, comunicação, riscos, abordagem, orçamento e cronograma.

No exemplo: objetivos: arquivo aceito pelo banco, zero duplicidade, sem regressão na remessa do Banco A. Abordagem baseada em risco. Critérios de saída: 100% das condições de risco alto executadas, nenhum defeito crítico ou alto aberto, homologação aprovada.

2. Monitoramento e controle: estamos no plano?

Compara o progresso real com o plano, usando as métricas definidas nele, e toma as ações necessárias para atingir os objetivos. Também avalia os critérios de saída: verifica a cobertura, avalia o nível de qualidade e decide se são necessários mais testes. Produz relatórios de progresso, contínuos, e relatórios de resumo, nos marcos. Relatório bom traz o que o público precisa para decidir.

No exemplo: na semana 4, 55% dos casos executados contra 70% previstos, e 62% das condições de risco alto contra 80%. Causa: sandbox fora do ar por dois dias. Ações de controle: priorizar a suíte de risco alto, alocar mais um tester por três dias e pedir ao banco uma janela dedicada.

3. Análise: o que testar?

Analisa a base de teste para definir e priorizar condições de teste, identificar as funcionalidades a cobrir e avaliar a testabilidade. A análise também procura defeitos na própria base: ambiguidades, omissões, inconsistências, imprecisões, contradições e afirmações supérfluas. Saídas: condições de teste priorizadas, ligadas por rastreabilidade aos elementos da base, e relatórios de defeitos da base.

No exemplo: a história US-09 ("título já enviado não reenvia") gera as condições CT-03 e CT-04. Na mesma análise aparece um defeito: o texto do layout do banco manda data em DDMMAAAA, e o exemplo do PDF usa AAAAMMDD. O defeito vai para o banco antes de existir uma linha de código.

4. Modelagem: como testar?

Transforma condições em casos de teste, priorizados, com apoio de técnicas como partição de equivalência, análise de valor-limite e tabela de decisão. Define os dados necessários, projeta o ambiente e identifica infraestrutura e ferramentas. O ambiente é projetado aqui; quem o constrói é a implementação. Casos de alto nível, sem valores concretos, são reutilizáveis entre ciclos.

No exemplo: o campo valor tem 13 posições inteiras e 2 decimais. Valor-limite: 0,00 (inválido), 0,01, 9.999.999.999.999,99 e 10.000.000.000.000,00 (inválido). Caso TC-03, de alto nível: "remessa com título já enviado e sem retorno de rejeição não gera segmento A".

5. Implementação: está tudo pronto para rodar?

Cria ou obtém o que falta para executar: procedimentos de teste priorizados, scripts automatizados, suítes, cronograma de execução, ambiente construído e verificado, dados preparados e carregados. É aqui que os casos de alto nível ganham valores concretos. Também confere e atualiza a rastreabilidade: toda condição tem caso? Todo caso tem condição?

No exemplo: validador de layout automatizado no pipeline; suítes smoke, risco alto e regressão Banco A; versão do validador fixada no ambiente.

6. Execução: o resultado real bate com o esperado?

Roda as suítes conforme o cronograma, manualmente ou com ferramentas. Registra IDs e versões do objeto de teste, das ferramentas e do testware; compara resultado real com esperado; analisa as anomalias antes de reportar; registra os resultados (passou, falhou, bloqueado); repete testes por correção, confirmação ou regressão. Saídas: status por teste, relatórios de defeitos e as versões envolvidas.

No exemplo: TC-03 falhou e gerou D-11 (duplicidade, crítico). TC-12 falhou e gerou D-14 (calendário sem feriados municipais). TC-09 também falhou, mas era falso positivo: o ambiente rodava o validador 2.2, com a regra antiga. Atualizado o validador, o teste passou. Não havia defeito no produto, e foi a versão registrada que permitiu descobrir isso.

7. Conclusão: o que entregamos e o que aprendemos?

Acontece nos marcos: fim de um nível de teste, de uma iteração, de uma release. Verifica se os defeitos foram fechados e registra como solicitações de mudança ou itens de backlog os que restaram. Cria o relatório de resumo, finaliza e arquiva ambiente, dados, infraestrutura e testware, e entrega o testware a quem vai mantê-lo. Analisa as lições aprendidas e usa o que aprendeu para melhorar a maturidade do processo.

No exemplo: um defeito de severidade média vira item de backlog. Validador, massa de dados e configuração do ambiente vão para a manutenção, reutilizáveis num futuro Banco C. Lições: validar as ambiguidades do layout com o banco antes da modelagem; incluir o calendário de feriados na base de teste desde o planejamento; reservar a janela do sandbox no cronograma.

Rastreabilidade: o que liga as atividades

Rastreabilidade é o vínculo entre cada elemento da base de teste e o testware associado a ele: condições, casos, procedimentos, suítes, resultados e defeitos. É estabelecido e mantido ao longo de todo o processo. Funciona nos dois sentidos. Da base para o testware, mostra cobertura: requisito sem condição de teste é lacuna. Do testware para a base, mostra por que cada teste existe: teste sem requisito é teste órfão.

No exemplo, a cadeia é: US-09 → CT-03 → TC-03 → suíte risco alto → ciclo 1: falhou (D-11) → ciclo 2: passou. Além de medir cobertura, ela serve para:

analisar o impacto de mudanças: quando o banco esclarece o formato da data, a cadeia lista as condições e os casos a revisar;
tornar o teste auditável: a evidência de que título enviado não reenvia é US-09 → TC-03 → log do ciclo 2;
atender critérios de governança de TI: evidência por requisito, sem retrabalho;
melhorar a compreensão dos relatórios: status por requisito (passou, falhou, pendente) em vez de contagem de casos;
traduzir o aspecto técnico para as partes interessadas: "reenvio de título já enviado está bloqueado e verificado", em vez de "TC-03 passou";
avaliar produto, processo e projeto: qualidade (1 crítico e 2 altos abertos), processo (D-14 aponta falha na base de teste) e projeto (62% do risco alto executado contra meta de 80%).

A cadeia pode viver numa ferramenta de gestão de teste ou num sistema próprio. A ferramenta é meio; o que importa é a cadeia existir e ser mantida.

Quem faz o quê

A gestão de teste responde pelo processo e pela equipe: planejamento, monitoramento e controle, conclusão. O papel de teste responde pela parte técnica: análise, modelagem, implementação e execução. Em times ágeis, a gestão pode ficar no próprio time.

Cinco erros comuns

Plano sem critério de saída: ninguém sabe quando parar.
Tratar toda anomalia como defeito: analisar antes de reportar evita falso positivo.
Rastreabilidade em um sentido só: esconde os testes órfãos.
Confundir modelagem com implementação: uma define como testar, a outra deixa tudo pronto para rodar.
Pular a conclusão: lições e testware se perdem.

Sete princípios dos teste de software

Yuri Peixinho — Sun, 04 Oct 2026 20:40:23 +0000

Introdução

Os sete princípios vêm do syllabus CTFL da ISTQB. São generalizações empíricas sobre o que teste consegue e não consegue fazer, usadas para calibrar expectativa e esforço. A numeração abaixo segue o CTFL 4.0.

Como agrupar

1, 2 e 7: limites do que teste pode garantir.
3 e 4: onde e quando alocar esforço.
5 e 6: como manter a abordagem eficaz ao longo do tempo e entre projetos.

1. Teste mostra a presença de defeitos, não a ausência

Teste reduz a probabilidade de defeitos não descobertos, mas não prova correção. A formulação clássica é de Dijkstra. Passar em 1.000 casos não garante o comportamento no 1.001º.

Exemplo:

A suíte de cálculo de juros e multa de boleto passa com 200 casos e quebra num vencimento em 29/02.

Implicação:

Reportar "nenhum defeito encontrado com esta cobertura e estes riscos", nunca "sem bugs".

2. Teste exaustivo é impossível

Testar todas as combinações de entradas, estados e pré-condições é inviável fora de casos triviais. Por isso existem técnicas de redução (partição de equivalência, análise de valor limite, tabela de decisão, pairwise) e priorização por risco.

Exemplo:

Um formulário com 10 campos e 5 valores relevantes por campo gera 5¹⁰ = 9.765.625 combinações.

Implicação:

Apergunta deixa de ser "testei tudo?" e passa a ser "testei o que tem mais risco, com o menor número de casos que cobre as classes de comportamento?".

3. Teste antecipado economiza tempo e dinheiro

Defeito achado em requisito ou design custa menos que o achado em produção. Isso inclui teste estático (revisão de requisitos e de código, análise estática), que encontra defeitos sem executar nada: o "shift left". Os multiplicadores clássicos (10x, 100x) vêm de dados antigos e são contestados, mas a direção do argumento se mantém.

Exemplo:

Uma ambiguidade na regra de arredondamento, apontada na revisão do requisito, vira uma conversa. Essa mesma descoberta depois do fechamento do mês em produção, vira correção, reprocessamento e acerto de dados.

4. Defeitos se agrupam

Poucos módulos concentram a maior parte dos defeitos. Costuma-se descrever isso pelo princípio de Pareto (80/20 como heurística, não como lei).

Exemplo:

3 de 40 módulos respondem por mais da metade dos bugs de produção.

Implicação:

Usar histórico de defeitos, churn de código e complexidade para direcionar o esforço (teste baseado em risco). Cuidado com o viés: um módulo pode parecer problemático só por ser o mais testado.

5. Os testes se desgastam (versão 3.1: "paradoxo do pesticida")

Repetir os mesmos testes deixa de encontrar defeitos novos, porque os que eles alcançavam já foram corrigidos. Isso não invalida regressão automatizada, cujo objetivo é detectar quebra, não achar defeito novo. O problema é depender só dela.

Exemplo:

30 cenários de checkout verdes há dois anos, sempre com o mesmo usuário e o mesmo cartão. Nenhum exercita cupom + frete grátis + estorno parcial.

Implicação:

Revisar e variar casos e dados periodicamente, complementar com teste exploratório e usar mutation testing para medir se a suíte detecta falhas de fato.

6. Teste depende do contexto

Não existe abordagem única. O que, quanto e como testar depende de risco, domínio, ciclo de vida, regulação e tecnologia.

Em aviônica (DO-178C, nível A) exige-se cobertura MC/DC e rastreabilidade formal, enquanto num MVP isso é desperdício. E-commerce com pico sazonal prioriza carga e performance. Sistema sob obrigação regulatória prioriza conformidade e rastreabilidade das regras.

7. A ausência de defeitos é uma falácia (versão 3.1: "falácia da ausência de erros")

Achar e corrigir todos os defeitos não adianta se o sistema não atende à necessidade do usuário. É a distinção entre verificação (construímos conforme a especificação?) e validação (construímos a coisa certa?).

Exemplo:

O sistema segue a especificação sem desvio algum, mas ela descrevia um fluxo que ninguém usa. Zero bugs, zero valor.

Implicação:

Incluir validação com usuário e negócio (teste de aceite, protótipo, feedback em produção), não só verificação contra requisito.

Introdução ao Teste de Software

Yuri Peixinho — Sun, 04 Oct 2026 01:31:04 +0000

Introdução

Testar um sistema não é apenas “rodar o programa e ver se não quebrou”. Formalmente, testes de software é o processo de avaliar um sistema para encontrar diferenças entre o comportamento esperado e o real, e construir confiança de que o sistema faz o que deveria fazer.

Duas noções que não podem ser confundidas:

Verificação: Are we building the product right? O software está de acordo com a especificação/design? É o território dos testes técnicos (unitários e integração)
Validação: Are we building the right product? O software resolve o problema real do negócio? É o território de aceitação, UAT, testes exploratórios.

Usando um caso real de testes para entender as duas noções na prática: GetDiferencaDataEmMeses_DeveRetornarDiferencaCorreta

Verificação: a função implementa corretamente a regra de cálculo de diferença em meses.
Validação: confirmar com a área de negócio que essa métrica é, de fato, a correta para aquele cálculo de benefício, o teste automatizado sozinho não garante isso.

Por que testamos: o custo crescente do erro

O argumento central é econômico: o custo de corrigir um defeito cresce exponencialmente quanto mais tarde ele é descoberto (o clássico "custo crescente do erro", popularizado por Boehm).

No domínio do usuário (BPO previdenciário/fiscal): um bug no cálculo de GetDiferencaAnos (que define elegibilidade a um benefício) encontrado por um teste unitário custa minutos. O mesmo bug encontrado em produção pode significar cálculo errado de benefício para centenas de participantes, retrabalho manual, risco regulatório (e-Financeira é fiscalização da Receita Federal) e dano de confiança.

Os três pilares de todo teste

Testar é uma atividade de equilíbrio entre três forças:

Correção: o sistema faz o que deveria fazer.
Confiança: o quanto a suíte de testes permite mudar o código sem medo. Esse é o verdadeiro ROI de testes: não é "achar bugs", é permitir mudança segura.
Custo: tempo para escrever, rodar e manter os testes. Testes mal escritos (frágeis, lentos, obscuros) podem custar mais do que valem.

Daqui vem um princípio que vai aparecer no curso inteiro: nem todo teste possível vale a pena escrever. Testar é otimização sob restrição de tempo, não busca por cobertura de 100%.

Gestão da Qualidade: QA vs. QC

Gestão da Qualidade é o guarda-chuva: tudo que a organização faz para direcionar e controlar qualidade. Dentro dela, duas disciplinas complementares:

	Garantia de Qualidade (QA)	Controle de Qualidade (QC)
Foco	Processo	Produto
Natureza	Preventiva	Detectiva
Pergunta	Estamos seguindo um processo que tende a gerar poucos defeitos?	Este artefato específico tem defeitos?
Atividades	Padrões, auditoria de processo, causa raiz, retrospectivas	Teste (unitário/integração/e2e), inspeção, code review
Efeito no tempo	Muda a curva de defeitos pra baixo ao longo dos releases	Atividades distribuídas ao longo de todo o ciclo ("mais à esquerda" — shift-left)

QC sem QA vira jogo infinito de achar bug (o processo continua gerando os mesmos tipos de defeito todo sprint). QA sem QC é teoria sem verificação (melhora o processo "no papel", sem dado real de que funcionou). Uma retroalimenta a outra.

A distinção QA/QC não é arbitrária, ela vem de um modelo mais amplo e bem antigo na gestão da qualidade, o Custo da Qualidade (Cost of Quality, Crosby/Juran), que divide todo investimento em qualidade em quatro categorias:

Categoria	O que é	Exemplo em software	Relação
Custos de Prevenção	Evitar que o defeito aconteça	Treinamento, revisão de requisito, definição de padrão de código	= QA
Custos de Avaliação	Encontrar o defeito antes de ir para produção	Testes automatizados,code review, inspeção	= QC
Custos de Falha Interna	Corrigir defeito encontrado antes do release	Retrabalho, re-teste, bug encontrado em homologação	Consequência de QC fraco
Custos de Falha Externa	Corrigir defeito encontrado depois do release	Incidente em produção, suporte, retrabalho de cálculo de benefício, multa regulatória	O topo da curva de custo crescente do erro (veja o gráfico acima)

O insight gerencial do modelo: gastar mais em Prevenção (QA) reduz Avaliação + Falha Interna + Falha Externa, com retorno maior que linear, é por isso que organizações maduras investem proporcionalmente mais em QA do que em QC pura, mesmo QC sendo a atividade mais visível (é a que "acha os bugs").

Uma confusão muito comum no mercado

Vale um alerta prático: na indústria, é extremamente comum um "time de QA" que, na prática, só faz QC (só testa o produto pronto) sem nenhum mandato real sobre processo. Isso não é um erro terminológico inofensivo: uma organização que chama sua função de teste de "QA" mas nunca faz análise de causa raiz nem muda processo está, na prática, sem QA nenhuma — só QC. O sintoma típico: os mesmos tipos de bug reaparecem release após release, porque ninguém fecha o loop.

O ciclo fechado, exemplo aplicado.

Juntando com o exemplo de causa raiz já visto:

QC encontra: um teste de integração (ou, pior, produção) acusa cálculo de benefício incorreto.
RCA aponta a causa raiz: regra de negócio mal especificada antes da codificação.
QA age no processo: passa a exigir revisão de requisito com 2 aprovadores de negócio antes de qualquer commit de regra de cálculo.
QC mede o resultado: nos sprints seguintes, a taxa de defeitos dessa categoria cai — e é esse dado (não a opinião de que "o processo melhorou") que valida se a ação de QA funcionou.

Sem o passo 4, você não sabe se a mudança de processo realmente ajudou — é só teoria. Sem o passo 3, você fica reagindo ao mesmo tipo de bug para sempre.

Causa raiz e o Princípio de Pareto

O fluxo de QA na prática: defeito encontrado → análise de causa raiz (5 porquês, diagrama de Ishikawa) → ação no processo → menos defeitos daquele tipo no futuro.

Aplicando Pareto (regra 80/20): atacar só as duas primeiras causas já endereça a maioria dos defeitos. A decisão gerencial correta não é "escrever mais testes genéricos" — é ação de processo cirúrgica: revisão de requisito com o time de negócio antes de codificar regras de cálculo (ataca a causa #1), e checklist obrigatório de casos de borda de data para qualquer função que manipule datas (ataca a causa #2).

Aprofundando: a técnica dos 5 Porquês

Exemplo aplicado (hipotético, mas realista para o domínio previdenciário):

Por que o cálculo de benefício retornou valor errado para o participante X? → Porque a função somou saldos de dois vínculos como se fossem um só.
Por que ela somou os dois vínculos? → Porque o código assume implicitamente que cada participante tem só um vínculo ativo por período.
Por que essa suposição foi codificada assim? → Porque o requisito original não mencionava o caso de múltiplos vínculos simultâneos.
Por que o requisito não mencionava isso? → Porque a área de negócio que escreveu o requisito não foi consultada sobre esse cenário (raro, mas existente).
Por que ninguém consultou a área de negócio sobre cenários raros? → Porque não há uma etapa formal de revisão de requisito com checklist de casos de borda antes da codificação.

A causa raiz real (passo 5) é de processo, não de código — "o dev esqueceu" (uma leitura preguiçosa do passo 1) seria a resposta errada se parássemos ali.

Armadilha comum: parar no primeiro "porquê" plausível e culpar uma pessoa em vez do processo. Isso é RCA malfeito. Você "resolve" repreendendo ou trocando uma pessoa, e o mesmo tipo de bug reaparece com o próximo desenvolvedor, porque a causa real (ausência de processo) nunca foi tocada.

Diagrama de Ishikawa (espinha de peixe)

Categoriza causas possíveis antes de investigar, para não convergir cedo demais numa hipótese única. Adaptação clássica dos "6M" para software:

Categoria	Pergunta	Exemplo no domínio
Método/Processo	O processo de desenvolvimento permitiu o defeito?	Falta de revisão de requisito
Pessoas	Faltou conhecimento/treinamento?	Novo dev não conhecia a regra de vínculos múltiplos
Ferramentas	A ferramenta/framework contribuiu?	ORM que esconde uma query N+1
Requisitos/Entrada	A especificação era ambígua ou incompleta?	Requisito não cobria vínculo duplo
Ambiente	Configuração de ambiente influenciou?	Fuso horário diferente em produção vs. dev
Dados	Dado de produção tinha formato inesperado?	Campo de data vindo nulo de um sistema legado

O efeito (o defeito) fica na "cabeça do peixe"; cada categoria vira uma "espinha" com possíveis causas listadas, até achar a raiz real.

Pareto: de onde vem, e uma armadilha

O princípio vem de Vilfredo Pareto (economista que observou que boa parte da terra na Itália pertencia a uma pequena fração da população) — Juran aplicou à qualidade como "os poucos vitais vs. os muitos triviais" (vital few vs. trivial many).

Armadilha gerencial: Pareto ordena por frequência, não necessariamente por severidade/custo. Uma causa raiz que aparece em 5% dos defeitos mas gera um incidente regulatório grave (ex.: erro fiscal que atrasa a entrega da e-Financeira) pode merecer prioridade maior que uma causa de 40% que só gera retrabalho interno barato. A regra prática correta: construa o Pareto por impacto (frequência × custo/severidade), não só por contagem bruta.

Fechando o loop: como saber se a ação de RCA funcionou

Depois de implementar a ação de processo (ex.: checklist de revisão de requisito), é preciso voltar a medir a mesma categoria de causa raiz nos próximos releases. Se a frequência não caiu, duas hipóteses: (1) a causa raiz identificada estava errada, ou (2) a ação de processo não foi realmente seguida na prática (processo no papel ≠ processo em execução) — o que puxa direto para o ponto já visto de que QA sem QC é teoria sem verificação.

Visão gerencial: garantindo testes eficientes no time

Três camadas resolvem isso: quando no processo, o que exigir estruturalmente, e como medir se está funcionando.

Regra prática: o caso de teste de aceitação é escrito no mesmo dia que o requisito, não depois que o código existe.

O que exigir estruturalmente

Definition of Done inclui teste. Uma história não está "pronta" sem teste automatizado correspondente.
Code review cobre o teste, não só a implementação. O revisor pergunta: esse teste falharia se eu reintroduzisse o bug?
CI como gate, não como relatório. PR com teste quebrando não mergeia (branch protection).

Como medir sem teatro de métricas

Cobertura de código (%) como meta vira teatro — testes que exercitam a linha sem afirmar nada relevante. Métricas mais honestas:

Taxa de escape de defeito — quantos bugs chegaram em produção vs. foram pegos antes.
Flaky test rate — testes que falham/passam aleatoriamente corroem a confiança no CI mais rápido que a ausência de testes.
Tempo de execução da suíte — suíte lenta = time para de rodar localmente = shift-left morre na prática.
Cobertura entra como sinalizador de risco, nunca como meta isolada de OKR.

Resumo: testes eficientes vêm de integrar teste como parte indissociável da definição de pronto desde o requisito, fechando o loop com análise de causa raiz dos defeitos que escaparem.

Estudo de caso: o Problema do Triângulo

Este é o exercício clássico de design de casos de teste (Glenford Myers, The Art of Software Testing). Especificação: um programa recebe 3 inteiros (lados) e responde escaleno, isósceles ou equilátero.

A armadilha pedagógica: a maioria escreve apenas 3 casos (um por classificação) e considera a suíte completa. Isso falha porque:

A especificação nunca disse que a entrada é sempre um triângulo válido — e se a soma de dois lados for menor que o terceiro (desigualdade triangular violada)?
O valor-limite exato, onde a soma de dois lados é igual ao terceiro (caso degenerado, "linha reta"), é onde bugs costumam viver.
Entrada inválida de domínio (zero, negativo) nem é uma pergunta geométrica — é validação de entrada.
Assimetria de implementação: um bug clássico é checar a==b e esquecer b==c isoladamente — por isso isósceles precisa de 3 variações (qual par é igual), não 1.

Suíte reconstruída — "efetiva" (encontra os bugs comuns) e razoavelmente "eficiente" (sem redundância boba):

#	a	b	c	Esperado	Categoria
1	2	3	4	Escaleno	válido, caso geral
2	2	2	3	Isósceles	1º e 2º iguais
3	2	3	2	Isósceles	1º e 3º iguais
4	3	2	2	Isósceles	2º e 3º iguais
5	5	5	5	Equilátero	todos iguais
6	1	2	10	Inválido	soma < terceiro lado
7	1	2	3	Inválido	soma = terceiro (valor-limite)
8	0	5	5	Inválido	lado zero
9	-1	5	5	Inválido	lado negativo

O ponto central: "efetivo" e "eficiente" não vêm de cobrir as saídas possíveis, vêm de pensar em como a implementação pode estar errada, ponte direta para as técnicas formais (particionamento de equivalência e análise de valor-limite).

Livro Head First Design Pattern: Encapsule o que varia

Yuri Peixinho — Sat, 03 Oct 2026 16:31:50 +0000

Introdução

No livro Head First Design Patterns ensina: não com a definição seca primeiro, mas com o problema que ele resolve. É assim que o livro faz com quase tudo — te mostra a dor antes da solução.

O princípio, em uma frase

Identifique os aspectos da sua aplicação que variam e separe-os do que permanece constante.

Ou seja: se uma parte do seu código muda com frequência (por causa de novos requisitos, novos tipos, novas regras de negócio) e outra parte é estável, não misture as duas. Isole a parte instável numa classe/interface própria, para que mudar uma coisa não quebre a outra.

O exemplo clássico do livro: o app dos patinhos (SimUDuck)

Imagine um app de simulação de lagoa com patos. Foi feito com uma classe abstrata Duck e subclasses como MallardDuck, RedheadDuck, etc. Cada uma herda quack() (grasnar) e swim() (nadar), e sobrescreve a aparência com display(). Design de herança clássico, e funciona bem — até que o chefe pede: "agora os patos precisam voar".

O Problema

A primeira ideia (ruim): adicionar fly() na classe Duck, já que herança é "reaproveitar código", certo?

Toda subclasse herda fly() automaticamente — inclusive o RubberDuck (pato de borracha), que não deveria voar. Agora você tem um pato de borracha voando pela tela. Você teria que sobrescrever fly() em cada subclasse que não deveria voar, e o mesmo aconteceria com quack() quando adicionarem um pato que não grasna.

Segunda ideia (também ruim): tirar fly() e quack() da superclasse e colocar em interfaces Flyable e Quackable, implementadas só pelos patos que precisam.

Interfaces não têm implementação (no Java clássico usado no livro). Cada subclasse que implementa Flyable precisa reescrever o próprio código de voar. Se 6 tipos de pato voam do mesmo jeito, você duplica o mesmo código 6 vezes. E se um dia mudar a lógica de voo, você corrige em 6 lugares.

Desenho do problema

!image.png

O que esse diagrama mostra

Duck define fly() diretamente na superclasse, junto com quack() e swim(). Toda subclasse herda os três automaticamente, sem escolha:

public abstract class Duck {
    public void quack() { System.out.println("Quack!"); }
    public void swim()  { System.out.println("Nadando..."); }
    public void fly()   { System.out.println("Voando!"); } // implementação padrão
}

public class MallardDuck extends Duck {
    // não sobrescreve nada — herda fly() e quack() como estão
}

public class RubberDuck extends Duck {
    public void quack() { System.out.println("Rangido de borracha."); }
    // esqueceu (ou nem pensou em) sobrescrever fly() — e agora ele voa
}

Por que isso é frágil, mesmo quando "funciona"

Repare que MallardDuck e RedheadDuck (azuis) não têm bug nenhum hoje — eles voam de verdade, então herdar fly() parece inofensivo. Mas o problema não é o bug do RubberDuck isoladamente; é que o comportamento está amarrado à árvore de herança, e essa árvore não tem como expressar "esse aqui não voa" sem sobrescrever método por método, subclasse por subclasse.

Isso significa duas coisas ruins:

Todo pato novo herda comportamento por padrão, e alguém precisa lembrar de corrigir manualmente quando o padrão não se aplica (como aconteceu com RubberDuck).
Mudar como voar funciona significa mexer na superclasse, arriscando afetar todo mundo que herda dela — mesmo patos que nunca deveriam ter sido afetados.

A correção "óbvia": tornar fly() abstrato e forçar cada subclasse a implementar o próprio, parece resolver, mas cria duplicação: se 10 tipos de pato voam do mesmo jeito, você repete o mesmo código de voo 10 vezes. Mudou a física do voo? Corrige em 10 lugares.

É exatamente esse impasse — herança rígida de um lado, duplicação do outro — que o encapsulate what varies resolve, tirando o comportamento variável da árvore de herança e colocando numa família de classes própria.

Solução

A ideia central: Duck não é mais definida por herança de comportamentos, ela tem (composição) uma referência a um FlyBehavior e a um QuackBehavior. Cada família de comportamento vira sua própria hierarquia, isolada e independente da hierarquia de patos.

Como fica o código

public interface FlyBehavior {
    void fly();
}

public class FlyWithWings implements FlyBehavior {
    public void fly() { System.out.println("Voando!"); }
}

public class FlyNoWay implements FlyBehavior {
    public void fly() { System.out.println("Não consigo voar."); }
}

E a classe Duck passa a delegar em vez de herdar diretamente o comportamento:

public abstract class Duck {
    FlyBehavior flyBehavior;
    QuackBehavior quackBehavior;

    public void performFly() {
        flyBehavior.fly();   // delega para o objeto de comportamento
    }

    public void performQuack() {
        quackBehavior.quack();
    }
}

public class MallardDuck extends Duck {
    public MallardDuck() {
        flyBehavior = new FlyWithWings();
        quackBehavior = new Quack();
    }
}

public class RubberDuck extends Duck {
    public RubberDuck() {
        flyBehavior = new FlyNoWay();   // agora é seguro: ele simplesmente não voa
        quackBehavior = new MuteQuack();
    }
}

Repare no que mudou:

O que varia (como voar, como grasnar) virou uma família de classes separada, cada uma com uma única responsabilidade.
O que é estável (a estrutura geral de um pato — nadar, ter aparência, existir na lagoa) continua em Duck.
Adicionar um novo tipo de voo (ex: FlyRocketPowered) não exige tocar em Duck nem em nenhuma subclasse existente — só criar uma nova classe que implementa FlyBehavior.
Você pode até trocar o comportamento em tempo de execução, já que é só uma referência a um objeto:

Isso já é o cheiro clássico de "o que varia não foi isolado".

!image.png

Por que esse é o primeiro princípio do livro

O livro coloca esse princípio logo no capítulo 1 porque ele é o raciocínio de base por trás de quase todos os outros padrões. Você acabou de ver, sem saber o nome, o esqueleto do Strategy Pattern, que é exatamente isso: encapsular uma família de algoritmos intercambiáveis (aqui, os algoritmos de voar e grasnar) atrás de uma interface comum, e deixar o objeto principal delegar para eles em vez de implementar diretamente.

Esse mesmo raciocínio ("o que muda, isolo; o que não muda, mantenho estável") reaparece depois em outros padrões do livro:

Observer encapsula "quem é notificado e como", separado do objeto que gera o evento.
Decorator encapsula "quais responsabilidades extras" um objeto ganha, sem mexer na classe original.
Factory Method encapsula "qual classe concreta instanciar", separado do código que usa o objeto. ****

Design Patterns (baixo nível)

Yuri Peixinho — Sat, 26 Sep 2026 23:05:37 +0000

Introdução

A ideia de "pattern" (padrão) não nasceu em software — veio do arquiteto Christopher Alexander, que nos anos 1970 catalogou soluções recorrentes para problemas de arquitetura civil e urbanismo, em seu livro A Pattern Language.

Em 1994, quatro autores — Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, apelidados de "Gang of Four" (GoF) — publicaram "Design Patterns: Elements of Reusable Object-Oriented Software", transportando essa ideia para a Programação Orientada a Objetos e catalogando 23 padrões, organizados em três categorias: Criacionais, Estruturais e Comportamentais.

Um pattern não é código pronto para copiar. É uma solução testada para um problema recorrente, documentada de forma abstrata o suficiente para se adaptar a contextos diferentes, mais parecida com uma receita estrutural do que com uma biblioteca.

Necessiade aplicada

Quando você programa orientado a objetos por tempo suficiente, alguns problemas/comportamentos se repetem, não a solução exata, mas o formato do problema:

Preciso trocar de comportamento em runtime sem um monte de if”;
Preciso que vários objetos saibam quando algo mudou
preciso criar um objeto complexo sem um construtor gigante

Como já dito acima, essencialmente, um design pattern é apenas isso. Uma solução já testada e batizada para um desses formatos de problema. Não é uma biblioteca que você importa, não é código pronto pra colar. É mais parecido com uma receita ou um esqueleto que você adapta para o seu caso específico.

A analogia que mais ajuda: é como aberturas de xadrez. Um jogador experiente reconhece a posição no tabuleiro e já sabe uma sequência de jogadas que historicamente funciona bem ali, mas ele adapta conforme o adversário reage, não copia cegamente. Design pattern é isso: reconhecer "ah, esse é um problema tipo X" e já entrar com uma estrutura que resolve bem esse tipo de problema.

Por que isso importa de verdade?

Vocabulário compartilhado

Quando um colega do time diz “aqui dá pra usar um Observer”, todo mundo que conhece o pattern já entendeu a ideia inteira na hora, sem precisar de um parágrafo explicando “ah, eu quero que vários objetos sejam avisados quando esse aqui mudar”. É um atalho de comunicação entre desenvolvedores.

Soluções já brigadas com a realidades

Alguém já tentou resolver esse problema de um jeito ingênuo, tomou a dor de cabeça de manutenção, e refinou até chegar numa estrutura que aguenta essa mudança sem quebrar tudo. Usar pattern é pular direto para a versão que já sobreviveu a esse processo.

Os dois princípios centrais

Todo o catálogo é uma aplicação repetida de dois mandamentos, estabelecidos no Capítulo 1 do livro:

"Programe para uma interface, não para uma implementação" — o código cliente depende de abstrações (interface/classe abstrata), nunca de classes concretas específicas.
"Prefira composição de objetos à herança de classes" — relações "tem um" (montadas em runtime) são mais flexíveis que relações "é um" (fixadas em tempo de compilação).

Praticamente todo pattern do catálogo existe para viabilizar um desses dois princípios em um cenário específico.

As três familias de Patterns

Criacional

Problemas de "como eu crio esse objeto sem virar bagunça?" Se seu objeto tem 8 parâmetros opcionais no construtor, ou se você precisa decidir em runtime qual classe concreta instanciar, é um problema criacional.

Estrutural

Problemas de "como eu encaixo essas peças pra formar algo maior?" Pensa em peças de LEGO: você quer que blocos diferentes se conectem de forma flexível, sem que um bloco precise saber os detalhes internos do outro.

Comportamental

Problemas de "quem fala com quem, e quem é responsável pelo quê?" É sobre distribuir responsabilidade e comunicação entre objetos sem criar uma teia de dependências onde tudo conhece tudo.

Tipo	O que define	Exemplos relevantes
Criacional	Como objetos são criados	Singleton, Factory, Builder
Estrutural	Como classes e objetos se organizam / relacionam	Adapter, Composite, Decorator
Comportamental	Como objetos interagem e se comunicam	Observer, Strategy, Mediator

Um exemplo único, para sentir a ideia geral

Esquece os 23 nomes e conceitos por um segundo e vamos focar em um só problema puro:

// Sem pattern nenhum: um "if" gigante que cresce toda vez que aparece um jeito novo de pagar
void ProcessarPagamento(string metodo, decimal valor)
{
    if (metodo == "cartao")
        Console.WriteLine($"Cobrando R${valor} no cartão...");
    else if (metodo == "pix")
        Console.WriteLine($"Gerando QR code de R${valor}...");
    else if (metodo == "boleto")
        Console.WriteLine($"Emitindo boleto de R${valor}...");
    // daqui a um mês: "criptomoeda", "paypal"... essa função nunca para de crescer
}

// Com pattern: cada forma de pagar é sua própria peça, intercambiável
interface IFormaPagamento
{
    void Processar(decimal valor);
}

class PagamentoCartao : IFormaPagamento
{
    public void Processar(decimal valor) => Console.WriteLine($"Cobrando R${valor} no cartão...");
}

class PagamentoPix : IFormaPagamento
{
    public void Processar(decimal valor) => Console.WriteLine($"Gerando QR code de R${valor}...");
}

____
IFormaPagamento forma = new PagamentoPix();
forma.Processar(150);
// forma nova? cria a classe, nunca mexe no código que já existe

Isso, especificamente, tem nome (Strategy), mas o que importa aprender primeiro é o raciocínio: identificar que "essa parte do código vai crescer e mudar" e já desenhar pra absorver mudança sem reescrever o que já funciona. O nome do pattern vem depois, é só o rótulo pra essa forma de pensar já ter sido catalogada antes de você.

O template da documentação do livro (13 elementos)

Cada um dos 23 padrões é descrito no livro seguindo exatamente esta estrutura fixa, que replicamos para cada padrão neste documento:

#	Elemento	O que descreve
1	Classificação	Nome do padrão + categoria (Purpose) + escopo (Scope)
2	Intent	O que o padrão faz, em uma frase
3	Also Known As	Apelidos alternativos, se existirem
4	Motivation	Um cenário concreto ilustrando o problema
5	Applicability	Situações em que o padrão se aplica
6	Structure	Representação das classes/relações envolvidas
7	Participants	Classes/objetos envolvidos e suas responsabilidades
8	Collaborations	Como os participantes interagem entre si
9	Consequences	Trade-offs — o que se ganha e o que se paga
10	Implementation	Armadilhas e técnicas de implementação
11	Sample Code	Código de exemplo (aqui, em C#)
12	Known Uses	Onde o padrão aparece em sistemas/frameworks reais
13	Related Patterns	Com quais outros padrões ele se confunde ou combina

Classificação Purpose x Scope

O livro classifica os padrões em duas dimensões: Purpose (o que o padrão faz) e o Scope (se a relação é fixada por herança em tempo de compilação — classe — ou montada dinamicamente por composição em runtime — objeto —

Scope \ Purpose	Criacional	Estrutural	Comportamental
Classe	Factory Method	Adapter (classe)	Template Method, Interpreter
Objeto	Abstract Factory, Builder, Prototype, Singleton	Adapter (objeto), Bridge, Composite, Decorator, Facade, Flyweight, Proxy	Chain of Responsibility, Command, Iterator, Mediator, Memento, Observer, State, Strategy, Visitor

Note que Adapter aparece nas duas linhas: é o único padrão do catálogo documentado com duas variantes — uma via herança (Classe) e outra via composição (Objeto), sendo a segunda a preferida na prática (coerente com o segundo princípio central).

POO: Scope / Visibility

Yuri Peixinho — Sat, 29 Aug 2026 17:10:53 +0000

Introdução

Se você não escrever nenhum modificador num membro de classe, ele vira private por padrão. E se você não escrever nenhum modificador numa classe de nível superior, ela vira internal por padrão.

class Veiculo // sem "public" aqui, seria "internal" por padrão
{
    double _combustivel; // sem modificador = private implícito — CUIDADO, é fácil esquecer
}

Tabela completa de todos os níveis, incluindo as combinações que ficaram de fora do desenho anterior:

Modificador	Quem acessa
`private`	só a própria classe
`protected`	a classe e suas subclasses, em qualquer assembly
`internal`	qualquer código no mesmo assembly (projeto/DLL)
`protected internal`	subclasses OU mesmo assembly (união dos dois)
`private protected`	subclasses E mesmo assembly ao mesmo tempo (interseção — C# 7.2+)
`public`	qualquer lugar
`file` (C# 11+)	só dentro do mesmo arquivo `.cs` — bem de nicho, usado em código gerado

Aplicado na nossa classe:

abstract class Veiculo
{
    private int _senhaAlarme = 4821;          // só Veiculo enxerga, nem subclasse vê
    protected double _quilometragem;           // Veiculo E suas subclasses enxergam
    internal string CodigoFrota = "FROTA-01";   // qualquer classe do mesmo projeto enxerga
    public string Placa { get; }                // literalmente qualquer um enxerga
}

Granularidade por acessor — isso é subestimado: getter e setter de uma mesma propriedade podem ter visibilidades diferentes:

public class Veiculo
{
    // getter público (todo mundo lê a velocidade), setter privado (só o próprio Veiculo muda)
    public double VelocidadeAtual { get; private set; }

    // getter protected internal (subclasses OU mesmo assembly), setter só pra subclasses
    protected internal double Odometro { get; protected set; }
}

Isso é como você escreve, no código de verdade, aquele princípio de "esconder o dado, expor uma leitura controlada" — sem precisar escrever um método GetVelocidade() manualmente.

Regra prática pra decidir:

Campo quase sempre private (exponha via propriedade se precisar); método que é só detalhe interno de implementação, private; algo que outras classes do mesmo módulo precisam mas o mundo de fora não, internal; parte do "contrato público" da sua classe, public. protected só quando você sabe que vai ter herança e a subclasse genuinamente precisa daquele acesso direto.

POO: Interfaces

Yuri Peixinho — Sat, 29 Aug 2026 17:06:18 +0000

Introdução

Um contrato puro. Tradicionalmente, zero implementação, zero estado só a assinatura do que um tipo promete saber fazer.

interface IAutonomo
{
    void Pilotar();
}

interface IEletrico
{
    double NivelBateria { get; }   // interface também pode ter propriedade, não só método
    void Recarregar();
}

Repare: dentro da interface você não escreve public — todo membro de interface já é implicitamente público, e você não pode restringir isso.

Uma classe pode implementar quantas interfaces quiser, além de herdar de uma única classe base:

class CarroAutonomo : Veiculo, IAutonomo, IEletrico
{
    private double _bateria = 100;

    public CarroAutonomo(string placa) : base(placa) { }

    public override void DescreverModo() => Console.WriteLine("Modo carro autônomo elétrico.");

    public void Pilotar() => Console.WriteLine("🤖 Dirigindo sozinho, sem motorista.");

    public double NivelBateria => _bateria;

    public void Recarregar()
    {
        _bateria = 100;
        Console.WriteLine("🔋 Bateria recarregada.");
    }
}

O nugget mais avançado: implementação explícita de interface, pra resolver conflito quando duas interfaces têm método com o mesmo nome:

interface IRelatorioFrota { string GerarRelatorio(); }
interface IRelatorioManutencao { string GerarRelatorio(); } // mesmo nome, contratos diferentes!

class Caminhao : Veiculo, IRelatorioFrota, IRelatorioManutencao
{
    public Caminhao(string placa) : base(placa) { }
    public override void DescreverModo() => Console.WriteLine("Modo caminhão: carga pesada.");

    // Implementação EXPLÍCITA: só acessível através do tipo da interface, não direto no objeto
    string IRelatorioFrota.GerarRelatorio() => "Relatório de frota: em rota";
    string IRelatorioManutencao.GerarRelatorio() => "Relatório de manutenção: revisão pendente";
}

Caminhao c = new Caminhao("CMN-01");

IRelatorioFrota rf = c;
Console.WriteLine(rf.GerarRelatorio()); // "Relatório de frota: em rota"

IRelatorioManutencao rm = c;
Console.WriteLine(rm.GerarRelatorio()); // "Relatório de manutenção: revisão pendente"

// c.GerarRelatorio() direto → ❌ nem compila, é ambíguo demais pra existir sem o "casting"

Interface Marcadora (marker interface)

Sem a implementação explícita, o compilador nem saberia qual das duas assinaturas você quis dizer. Com ela, cada versão "mora" dentro do tipo da interface específica.

Interface marcadora (marker interface): uma interface vazia, sem nenhum membro, usada só pra "carimbar" um tipo:

interface IInspecionavel { } // vazia de propósito

class Caminhao : Veiculo, IInspecionavel { /* ... */ }

if (veiculo is IInspecionavel) 
    Console.WriteLine("Precisa passar por inspeção periódica.");

POO: Classes Concretas

Yuri Peixinho — Sat, 29 Aug 2026 16:43:31 +0000

Introdução

Uma classe é concreta quando está 100% implementada. Nenhum membro fica pendurado sem corpo. É por isso, e so por isso que o compilador libera o new.

Vamos ver a anatomia completa de uma classe concreta, com todas as peças que ela pode ter:

class Carro
{
    // Campo privado: o dado bruto, cru
    private double _combustivelLitros;

    // Propriedades: a porta de entrada controlada
    public string Placa { get; }                 // só leitura fora do construtor
    public string Modelo { get; set; }
    public double VelocidadeAtual { get; private set; } // lê de fora, só a própria classe muda

    // Membro estático e constante: pertencem à CLASSE, não a cada objeto
    public const double CapacidadeTanqueMaxima = 50.0;
    private static int _totalCarrosCriados = 0;

    // Construtor principal
    public Carro(string placa, string modelo, double combustivelInicial)
    {
        Placa = placa;
        Modelo = modelo;
        _combustivelLitros = combustivelInicial;
        _totalCarrosCriados++;
    }

    // Construtor sobrecarregado, encadeando no principal com "this(...)"
    public Carro(string placa, string modelo) : this(placa, modelo, combustivelInicial: 10)
    {
    }

    public void Acelerar(double incremento)
    {
        if (_combustivelLitros <= 0)
        {
            Console.WriteLine($"{Modelo} está sem combustível!");
            return;
        }
        VelocidadeAtual += incremento;
        _combustivelLitros -= 0.5;
    }

    public static int TotalCriados() => _totalCarrosCriados;
}

Vale destrinchar cada detalhe:

Placa sem set. Só pode ser atribuída dentro do construtor. Depois disso, é imutável pra sempre. É a forma mais simples de garantir que uma placa nunca muda depois de criada.
_totalCarrosCriados estático, ***não pertence a nenhum carro específico, pertence à *classe Carro inteira. Incrementa toda vez que qualquer carro nasce, e é compartilhado entre todas as instâncias.
Dois construtores — o segundo delega pro primeiro via : this(...), evitando duplicar a lógica de inicialização. É overloading de construtor, o mesmo mecanismo do overloading de método.

Instanciando:

var meuCarro = new Carro("ABC-1234", "Modelo X", combustivelInicial: 40); // usa o construtor completo
var outroCarro = new Carro("DEF-5678", "Modelo Y"); // usa o construtor curto, com 10L de combustível padrão

Quando usar só uma classe concreta, sem hierarquia nenhuma: quando não existe variação de comportamento por tipo. Se só vai existir um jeito de "Carro" existir no seu sistema — sem carro elétrico, autônomo, etc. — criar uma hierarquia complexa é over-engineering. Comece simples, só introduza abstract/interface quando a variação aparecer de verdade.

Erro comum: a "God Class" — uma classe concreta que vai crescendo e acumulando responsabilidades demais (Carro cuidando de motor, de pagamento do aluguel, de geolocalização, de manutenção...). É sintoma de que faltou dividir em outras classes menores — ligação direta com o "S" do SOLID que já vimos.

POO: Polimorfismo

Yuri Peixinho — Fri, 21 Aug 2026 23:26:48 +0000

Introdução

Imagina que você tá fazendo um jogo com vários tipos de monstro, mas ainda sem polimorfismo. Cada monstro é só um "tipo" e uma função central decide o que cada um faz:

void Atacar(string tipoMonstro)
{
    if (tipoMonstro == "Dragao")
        Console.WriteLine("🔥 Cospe uma bola de fogo!");
    else if (tipoMonstro == "Fantasma")
        Console.WriteLine("👻 Atravessa a parede e assusta!");
    else if (tipoMonstro == "Slime")
        Console.WriteLine("🟢 Pula e gruda em você!");
    // toda vez que você inventa um monstro novo, tem que vir AQUI e adicionar mais um "else if"
}

Isso funciona, mas é uma bomba-relógio: essa função vai crescer pra sempre, e todo mundo que mexe no jogo precisa saber que ela existe e lembrar de atualizá-la. É frágil e cansativo.

A ideia central do polimorfismo

Em vez de uma função central que pergunta "que tipo é você?", cada monstro já sabe se comportar sozinho. Você não pergunta, você só manda:

**abstract** class Monstro
{
    public string Nome { get; }
    public int Vida { get; protected set; } = 100;

    protected Monstro(string nome) => Nome = nome;

    public abstract void Atacar();

    public virtual void TomarDano(int dano)
    {
        Vida -= dano;
        Console.WriteLine($"{Nome} perdeu {dano} de vida (restam {Vida}).");
    }
}

E cada monstro implementa sua própria versão:

class Dragao : Monstro
{
    public Dragao() : base("Dragão") { }
    public override void Atacar() => Console.WriteLine($"{Nome} 🔥 cospe uma bola de fogo!");
}

class Fantasma : Monstro
{
    public Fantasma() : base("Fantasma") { }
    public override void Atacar() => Console.WriteLine($"{Nome} 👻 atravessa a parede e assusta!");

    public override void TomarDano(int dano)
    {
        int danoReal = dano / 2; // é intangível, sofre metade do dano
        Console.WriteLine($"{Nome} é intangível — dano reduzido pela metade!");
        base.TomarDano(danoReal);
    }
}

class Slime : Monstro
{
    public Slime() : base("Slime") { }
    public override void Atacar() => Console.WriteLine($"{Nome} 🟢 pula e gruda em você!");
}

class Golem : Monstro
{
    public Golem() : base("Golem") { Vida = 200; } // é um tanque, vida maior
    public override void Atacar() => Console.WriteLine($"{Nome} 🪨 esmaga o chão com o punho!");
}

Repara que Fantasma não só ataca diferente — ele reage a dano diferente também, porque sobrescreveu TomarDano. Cada classe carrega sua própria lógica, não só um texto diferente.

Colocando pra rodar: a batalha completa

List<Monstro> inimigos = new() { new Dragao(), new Fantasma(), new Slime(), new Golem() };

foreach (var inimigo in inimigos)
{
    inimigo.Atacar();
    inimigo.TomarDano(30);
    Console.WriteLine();
}

Saída:

Dragão 🔥 cospe uma bola de fogo!
Dragão perdeu 30 de vida (restam 70).

Fantasma 👻 atravessa a parede e assusta!
Fantasma é intangível — dano reduzido pela metade!
Fantasma perdeu 15 de vida (restam 85).

Slime 🟢 pula e gruda em você!
Slime perdeu 30 de vida (restam 70).

Golem 🪨 esmaga o chão com o punho!
Golem perdeu 30 de vida (restam 170).

Mesmo código (inimigo.Atacar(), inimigo.TomarDano(30)) rodando pra quatro tipos diferentes, cada um reagindo do seu próprio jeito. Zero if, zero switch.

O verdadeiro poder: extensibilidade

Quer adicionar um Vampiro que rouba vida ao atacar? Você cria a classe...

class Vampiro : Monstro
{
    public Vampiro() : base("Vampiro") { }
    public override void Atacar() => Console.WriteLine($"{Nome} 🧛 morde e rouba sua vida!");
}

...e pronto. Não precisa tocar em nenhuma linha da lista, do foreach, ou de qualquer código que já existia. Isso é o Princípio Aberto/Fechado (aquele "O" do SOLID) na prática: o sistema está aberto pra crescer, mas fechado pra você precisar reabrir e editar o que já funciona.

Os dois tipos de polimorfismo (pra fechar com chave de ouro)

Tudo que fizemos até aqui é polimorfismo em tempo de execução (via override) — o mais importante e o que todo mundo quer dizer quando fala "polimorfismo" em POO. Mas existe um segundo tipo, mais simples, decidido em tempo de compilação: sobrecarga de métodos.

class Curandeiro
{
    public void Curar(Monstro alvo) => alvo.TomarDano(-20); // cura um
    public void Curar(List<Monstro> aliados) 
    {
        foreach (var a in aliados) a.TomarDano(-20); // cura vários
    }
}

Aqui o compilador escolhe qual Curar chamar baseado nos argumentos que você passa — antes mesmo do programa rodar. Não tem nada de dinâmico, é só "mesmo nome, assinaturas diferentes".

Como o C# sabe qual versão rodar

A parte que parece mágica: repare que a lista é List<Monstro>, não List<Dragao> ou qualquer coisa específica.

Monstro m = new Fantasma();
m.Atacar(); // roda a versão do Fantasma, mesmo "m" sendo do tipo Monstro

O C# decide qual Atacar() rodar olhando pro tipo real do objeto guardado na memória — não pro tipo da variável que você usou pra referenciar ele. É por isso que o foreach funciona perfeitamente numa lista cheia de tipos misturados: em cada volta, o objeto "lembra" quem ele realmente é.

POO: Herança

Yuri Peixinho — Fri, 21 Aug 2026 22:55:28 +0000

Introdução

Uma classe (subclasse/derivada) reaproveita estrutura e comportamento de outra (superclasse/base), podendo especializar o que for necessário.

class Funcionario
{
    public string Nome { get; set; }
    protected decimal SalarioBase;

    public Funcionario(string nome, decimal salarioBase)
    {
        Nome = nome;
        SalarioBase = salarioBase;
    }

    public virtual decimal CalcularSalario() => SalarioBase;
}

class Gerente : Funcionario
{
    private decimal _bonus;

    public Gerente(string nome, decimal salarioBase, decimal bonus) 
        : base(nome, salarioBase)
    {
        _bonus = bonus;
    }

    public override decimal CalcularSalario() => base.CalcularSalario() + _bonus;
}

Repare em três mecanismos importantes:

: base(nome, salarioBase) — chama o construtor da classe pai.
virtual na base — sinaliza "isso pode ser reescrito".
override + base.CalcularSalario() — reescreve mas ainda reaproveita a lógica original.

Tipos de relação que herança modela

Regra de ouro é o teste "é um" (is-a): Gerente é um Funcionario. Se a relação real é "tem um" (has-a), a resposta certa é composição, não herança — Carro tem um Motor, não deveria herdar de Motor. O livro “Head First Design Pattern”, aborda de forma eficiente sobre preferir composições ao invés de herança.

sealed trava a herança:

sealed class RelatorioFinal : Funcionario /* ninguém pode herdar disso */

Útil quando você quer garantir que o comportamento não será alterado por subclasses além de ser bom pra segurança e pra o compilador otimizar chamadas (sem precisar checar override em runtime).

A armadilha da herança profunda: cada nível adiciona acoplamento. Se Funcionario → Gerente → GerenteRegional → DiretorRegional, uma mudança lá em cima em Funcionario pode quebrar comportamento três níveis abaixo de um jeito difícil de rastrear. Regra prática: se você passar de 2 níveis de herança, pare e pergunte se composição resolveria melhor (voltamos nisso na conversa anterior, com o exemplo do IComportamentoVoo).

C# não tem herança múltipla de classes (só de interfaces) — justamente pra evitar o "problema do diamante": se C herdasse de A e B, e ambos tivessem um método Fazer(), qual implementação C usaria? C# resolve isso simplesmente proibindo.

Exemplo de jogo

Temos uma classe Personagem e agora criamos tipos especializados que reaproveitam tudo que Personagem já tem:

class Personagem
{
    // ...
    public void Atacar(Personagem alvo)
    {
        int dano = CalcularDano();          // fórmula escondida
        alvo.TomarDano(dano);
        Console.WriteLine($"{Nome} atacou {alvo.Nome} causando {dano} de dano!");
    }

    private int CalcularDano()
    {
        bool critico = new Random().Next(100) < 15; // 15% de chance
        int danoBase = 20;
        return critico ? danoBase * 2 : danoBase;
    }
}

class Guerreiro : Personagem
{
    public int Armadura { get; set; }
    public Guerreiro(string nome) : base(nome, vidaMaxima: 150) { Armadura = 20; }
}

class Mago : Personagem
{
    public int Mana { get; private set; } = 100;
    public Mago(string nome) : base(nome, vidaMaxima: 80) { }
}

class Arqueiro : Personagem
{
    public Arqueiro(string nome) : base(nome, vidaMaxima: 100) { }
}

Guerreiro, Mago e Arqueiro ganham Nome, Vida, Atacar(), TomarDano() e Curar() de graça — não precisaram reescrever nada disso. Cada um só adiciona o que é específico dele (Armadura, Mana).

POO: Abstração

Yuri Peixinho — Fri, 21 Aug 2026 22:46:15 +0000

Introdução

Definição: expor o "o quê" e esconder o "como". É a diferença entre uma interface de operação e sua implementação.

Isso normalmente é confundido com encapsulamento, mas são coisas diferentes: encapsulamento é sobre proteção do estado; abstração é sobre simplificação da complexidade — reduzir um problema complexo a um modelo mais simples de interagir.

public interface INotificador
{
    void Enviar(string mensagem, string destinatario);
}

public class NotificadorEmail : INotificador
{
    public void Enviar(string mensagem, string destinatario)
    {
        // conecta em SMTP, monta o corpo do e-mail, trata retry, etc — tudo escondido
        Console.WriteLine($"E-mail enviado para {destinatario}");
    }
}

public class NotificadorSms : INotificador
{
    public void Enviar(string mensagem, string destinatario)
    {
        // chama API de SMS, formata número, etc — também escondido
        Console.WriteLine($"SMS enviado para {destinatario}");
    }
}

Quem usa INotificador não sabe (nem precisa saber) se por trás tem uma chamada SMTP ou uma API REST de SMS. Só conhece o contrato: Enviar(mensagem, destinatario).

Níveis de abstração — pense numa aplicação em camadas: Controller chama IPedidoService, que chama IPedidoRepository, que fala com o banco. Cada camada abstrai a complexidade da camada de baixo. Isso é abstração acontecendo em escala arquitetural, não só numa classe.

Abstração vazada (leaky abstraction) é o antipadrão aqui: quando detalhes de implementação "vazam" pro contrato. Exemplo clássico: um método INotificador.Enviar() que lança SmtpException — isso força quem usa a interface a conhecer detalhes de uma implementação específica (e-mail), quebrando a abstração.

Exemplo aplicado a jogo

Quando você aperta "Atacar" no controle, você não calcula chance de crítico, multiplicador elemental, redução por armadura — o jogo esconde essa complexidade toda atrás de um botão simples. Isso é abstração.

class Personagem
{
    // ...
    public void Atacar(Personagem alvo)
    {
        int dano = CalcularDano();          // fórmula escondida
        alvo.TomarDano(dano);
        Console.WriteLine($"{Nome} atacou {alvo.Nome} causando {dano} de dano!");
    }

    private int CalcularDano()
    {
        bool critico = new Random().Next(100) < 15; // 15% de chance
        int danoBase = 20;
        return critico ? danoBase * 2 : danoBase;
    }
}

Quem chama personagem.Atacar(inimigo) não faz ideia de que existe cálculo de crítico rolando por trás. Só vê a ação. É exatamente essa "caixa preta simples por fora, complexa por dentro" que é a abstração.

POO: Encapsulamento

Yuri Peixinho — Fri, 21 Aug 2026 22:42:23 +0000

Introdução

O conceito de encapusalento é primordial para proteger nossas classes. Vamos ser didáticos aqui e fingir que estamos desenvolvendo um jogo de RPG. Pensa na vida (HP) do personagem como aquela barrinha vermelha no topo da tela. Se qualquer parte do código puder mexer nela direto, é fácil alguém, por engano, jogar a vida pra -500 ou deixar passar do máximo — bug feio, barra quebrada.

class Personagem
{
    public string Nome { get; }
    public int VidaMaxima { get; }
    private int _vida;              // ninguém mexe aqui de fora
    public int Vida => _vida;       // só leitura

    public Personagem(string nome, int vidaMaxima)
    {
        Nome = nome;
        VidaMaxima = vidaMaxima;
        _vida = vidaMaxima;
    }

    public void TomarDano(int dano)
    {
        _vida = Math.Max(0, _vida - dano);       // nunca fica negativo
        if (_vida == 0) Console.WriteLine($"{Nome} foi derrotado!");
    }

    public void Curar(int quantidade)
    {
        _vida = Math.Min(VidaMaxima, _vida + quantidade); // nunca passa do máximo
    }
}

Repara: personagem.Vida = -50; nem compila. A única forma de mexer na vida é passando pelas regras (TomarDano, Curar), que garantem que ela nunca sai do intervalo válido. Isso é encapsulamento — o dado protegido pela lógica que mora junto dele.

Um detalhe importante é: não é só "usar private", é agrupar dados e o comportamento que os manipula, escondendo os detalhes internos e expondo uma interface controlada. O objetivo é garantir que o objeto nunca fique num estado inválido.

Os dois níveis de encapsulamento

Dois níveis de encapsulamento que gente costuma confundir:

Data hiding — esconder os campos (private decimal _saldo).
Information hiding (mais amplo) — esconder a implementação, não só os dados. Exemplo: trocar a implementação interna de uma Lista de array pra lista ligada sem que ninguém que usa a classe perceba.

Nível de acesso em C

É importante e cai muito bem dominar todos, não só o public/private

public class Exemplo
{
    private int _a;      // só dentro da própria classe
    protected int _b;    // classe e subclasses
    internal int _c;     // mesmo assembly
    protected internal int _d; // subclasses OU mesmo assembly
    private protected int _e;  // subclasses DENTRO do mesmo assembly
    public int _f;       // qualquer um
}

Erro comum

Um erro comum é expor um campo mutável de referência (lista, array) via getter público quebra o encapsulamento mesmo com private set:

class Pedido
{
    private List<string> _itens = new();
    public List<string> Itens => _itens; // PERIGO: quem chamar Itens.Add() muda o estado interno direto
}

O fix é retornar uma cópia ou uma interface somente-leitura: IReadOnlyList<string> Itens => _itens.AsReadOnly();