DEV Community: Yuri Peixinho

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();

Programação Orientada a Objetos

Yuri Peixinho — Fri, 21 Aug 2026 22:31:07 +0000

Introdução

Programação Orientada a Objetos é um paradigma (um jeito de organizar código) onde você modela o problema como um conjunto de objetos que têm estado (dados) e comportamento (métodos), em vez de modelar como uma sequência de instruções que manipulam dados soltos.

A ideia central: em vez de separar "dados" de um lado e "funções que mexem nos dados" do outro, você agrupa os dois numa única unidade — o objeto.

Pra que serve / que problema resolve

Antes da POO ficar popular, a programação era predominantemente procedural: um monte de funções manipulando estruturas de dados globais ou passadas por parâmetro. Isso funciona bem em programas pequenos, mas cresce mal:

// Estilo procedural
struct ContaBancaria
{
    public decimal Saldo;
}

void Sacar(ref ContaBancaria conta, decimal valor)
{
    conta.Saldo -= valor; // nada impede alguém de fazer conta.Saldo = -9999 direto
}

Qualquer parte do código pode mexer em Saldo sem passar pelas regras de negócio. Conforme o sistema cresce, fica impossível garantir que os dados estão sempre num estado válido.

A POO ataca esse problema principal: acoplar dados às regras que os protegem, e além disso:

Organiza sistemas grandes em pedaços independentes e reutilizáveis
Modela o domínio do problema de um jeito mais próximo de como pensamos no mundo real (um Cliente, um Pedido, uma ContaBancaria)
Facilita manutenção: mudanças ficam localizadas dentro da classe responsável

// Estilo orientado a objetos
class ContaBancaria
{
    public decimal Saldo { get; private set; }

    public void Sacar(decimal valor)
    {
        if (valor > Saldo)
            throw new InvalidOperationException("Saldo insuficiente");
        Saldo -= valor;
    }
}

Agora é impossível deixar o saldo inválido de fora da classe — a regra mora junto com o dado.

Classe vs Objeto

Essa distinção é a base de tudo:

Classe é o molde/template — a definição de que atributos e comportamentos algo terá.
Objeto (ou instância) é uma "coisa concreta" criada a partir desse molde.

csharp

class Carro // classe: o molde
{
    public string Modelo { get; set; }
    public int Velocidade { get; set; }

    public void Acelerar() => Velocidade += 10;
}

Carro meuCarro = new Carro { Modelo = "Civic" };   // objeto 1
Carro carroDoAmigo = new Carro { Modelo = "Corolla" }; // objeto 2

Carro é uma classe só. meuCarro e carroDoAmigo são dois objetos independentes, cada um com seu próprio estado.

Por que isso importa na prática

O ganho real não é "seguir um paradigma bonito", é que sistemas orientados a objetos bem feitos tendem a ser mais fáceis de estender sem quebrar o que já existe, mais fáceis de testar (cada objeto isolado), e mais fáceis de entender porque o código espelha o vocabulário do problema real.

Aprofundamentos (Visão Geral)

Ao entender o que o POO resolve na prática, seremos capazes de entrar nos pilares e conceitos fundamentais.

São eles:

Principais Pilares
Funcionalidades do Paradigma
Model-Driven Design

Livro Head First Design Pattern: Prefira composição em vez de herança

Yuri Peixinho — Sat, 08 Aug 2026 16:51:44 +0000

Introdução

Herança modela uma relação "é um" (is-a): MallardDuck é um Duck. Composição modela uma relação "tem um" (has-a): Duck tem um FlyBehavior.

O princípio diz: quando você precisa reutilizar código ou compor comportamento, prefira montar um objeto a partir de peças menores (composição) a herdar de uma superclasse cada vez mais inchada. Isso não significa banir herança — significa não usá-la como ferramenta padrão para todo tipo de reuso.

Por que herança vira um problema

Você herda comportamento, mas herda tudo, mesmo o que não serve. E como a subclasse é compilada contra a estrutura interna da superclasse, qualquer mudança na superclasse se propaga — às vezes de forma inesperada — para toda a árvore de descendentes. Isso é chamado de fragile base class problem (problema da classe-base frágil): você não consegue mais mexer na classe-mãe com segurança, porque não sabe quais das dezenas de subclasses dependem de algum detalhe interno dela.

O sintoma mais visível, porém, é a explosão combinatória: quando um comportamento varia em mais de uma dimensão, cada combinação nova de dimensões vira uma classe nova.

!image.png

Repare no padrão: são só 2 dimensões (voa ou não / faz som ou fica mudo), cada uma com 2 opções, e isso já gera 4 classes concretas. Some uma terceira dimensão — digamos, cor da plumagem, com 2 variações — e você pula para 8 classes. É crescimento multiplicativo, não aditivo: 2x2x2 = 8, não 2 + 2 + 2 = 6. Cada combinação nova de comportamentos que alguém pedir vira uma classe nova, e a maior parte do código dentro dela é cópia com pequenas variações.

A Correção

Em vez de Duck ramificar em subclasses por combinação de comportamento, Duck passa a compor dois objetos independentes — um FlyBehavior e um QuackBehavior — e delega a eles:

abstract class Duck {
    FlyBehavior flyBehavior;
    QuackBehavior quackBehavior;
    // ...
}

Com isso, 2 variações de voo + 2 variações de som não geram 4 classes — geram 2 + 2 = 4 objetos de comportamento, que são livremente combinados em qualquer Duck. Ao adicionar uma terceira dimensão, você não multiplica: apenas soma mais uma família de comportamentos independente. É o mesmo diagrama de composição que te mostrei antes, só que agora você já entende o problema que ele existe para evitar.

Quando herança ainda é a escolha certa

O princípio não é "nunca use herança" — é "não use herança como padrão automático". Ela continua sendo a ferramenta certa quando:

a relação é-um é genuinamente verdadeira e estável (um Círculo é uma Forma, e sempre será);
as subclasses respeitam o Liskov Substitution Principle — qualquer subclasse pode substituir a superclasse sem quebrar expectativas de quem usa;
a hierarquia é rasa (1-2 níveis) e não vai crescer em múltiplas dimensões independentes;
você quer reaproveitar uma implementação já testada e não espera variação de comportamento em runtime.

O sinal de alerta para trocar por composição é quando você percebe que está adicionando um método a uma subclasse só para sobrescrevê-lo como vazio ou lançar UnsupportedOperationException (RubberDuck.fly() { }) — isso é sintoma clássico de que a hierarquia está forçando um comportamento que não pertence a todos os descendentes.

Padrões que existem para viabilizar composição

Vários padrões do catálogo GoF são, na prática, formas estruturadas de aplicar este princípio:

Strategy — comportamento intercambiável via composição (FlyBehavior).
Decorator — adiciona responsabilidades a um objeto envolvendo-o em outro objeto com a mesma interface, em vez de criar uma subclasse para cada combinação de responsabilidades (ex: CoffeeWithMilk, CoffeeWithMilkAndSugar... vira apenas decoradores empilhados).
Composite — monta estruturas de árvore (parte-todo) compondo objetos recursivamente, sem hierarquia de herança rígida entre "folha" e "galho".
Bridge — separa uma abstração da sua implementação em duas hierarquias independentes que se compõem, exatamente para evitar a explosão combinatória que o diagrama acima mostra.

O problema do "diamante" (bônus em linguagens com herança múltipla)

Em linguagens que permitem herdar de mais de uma classe (C++, Python), a explosão de herança pode gerar um problema extra: se ClasseD herda de ClasseB e ClasseC, e ambas herdam de ClasseA, qual versão de um método sobrescrito em B e C prevalece em D? Isso é o diamond problem, e é uma das razões pelas quais Java e C# nunca permitiram herança múltipla de classes — só de interfaces (que não carregam implementação, então o conflito não existe). Composição simplesmente não sofre disso: você nunca tem ambiguidade sobre "de qual pai herdei esse método", porque não há herança nenhuma envolvida.

Resumo

	Herança	Composição
Relação modelada	é-um	tem-um
Acoplamento	forte (subclasse depende da estrutura interna da superclasse)	fraco (depende só da interface do componente)
Variação em N dimensões	multiplicativa (classes explodem)	aditiva (soma componentes)
Troca de comportamento	fixada em tempo de compilação	pode mudar em tempo de execução (`setFlyBehavior`)
Risco principal	fragile base class problem	mais indireção, mais peças para montar mentalmente
Quando usar	relação é-um genuína, hierarquia rasa e estável	comportamento varia, ou varia em mais de uma dimensão

Hollywood Principle

Yuri Peixinho — Sat, 08 Aug 2026 16:03:52 +0000

Introdução

O Hollywood Principle é um princípio de design de software resumido na frase "Don't call us, we'll call you" — não nos chame, nós chamaremos você. É a mesma frase clássica usada por produtores em Hollywood para dispensar atores em audições sem se comprometer a retornar contato.

Em código tradicional, o seu programa controla o fluxo: ele chama bibliotecas, decide a ordem das operações e "puxa" o que precisa. No Hollywood Principle isso se inverte — um componente de nível mais alto (um framework, por exemplo) mantém o controle do fluxo, e é ele quem chama o seu código, no momento que julgar apropriado, e não o contrário.

Por isso o princípio é praticamente sinônimo de Inversão de Controle (IoC): você não chama o framework, o framework chama você.

Biblioteca vs. framework

Essa é a forma mais prática de sentir o princípio no dia a dia:

Biblioteca: você importa, você chama os métodos, você está no comando. Ex.: usar Math.Sqrt() ou uma lib de parsing de JSON.
Framework: ele define a estrutura da aplicação, e o seu código só "encaixa" nos pontos que ele espera. Ex.: você escreve um método OnClick() e o WinForms decide quando chamá-lo; você escreve uma classe Controller no ASP.NET Core e o runtime decide quando instanciá-la e invocar seus métodos.

Resumindo em uma frase: não chame o framework, o framework chama você.

Exemplos em C

1. Loop manual vs. evento

// Fluxo tradicional: você fica perguntando, você está no comando
while (true)
{
    var evento = filaDeEventos.PegarProximo();  // você decide quando pegar
    if (evento.Tipo == TipoEvento.Clique)
    {
        TratarClique(evento);                   // você chama sua própria função
    }
}

// Hollywood principle: você registra e espera ser chamado
void TratarClique(object sender, EventArgs e)
{
    Console.WriteLine("botão clicado!");
}

botao.Click += TratarClique;   // "não me chame, eu te chamo"
Application.Run(formulario);   // o framework entra em loop e chama
                                // TratarClique quando o clique acontecer

No primeiro caso, TratarClique aparece no seu código sendo chamada por você. No segundo, ela nunca é chamada por você em lugar nenhum — só é passada como referência (um delegate). Quem decide quando ela roda é o Application.

2. `OrderBy` com seletor: um mini-Hollywood dentro do LINQ

int Prioridade(Pessoa p) => p.Idade;

var pessoasOrdenadas = pessoas.OrderBy(Prioridade);

Você nunca escreve Prioridade(pessoas[0]), Prioridade(pessoas[1])... Quem chama Prioridade, quantas vezes e em que ordem, é o algoritmo de ordenação dentro do OrderBy. Isso já é o princípio agindo, mesmo dentro de um método LINQ comum.

3. xUnit (framework de testes)

public class CalculadoraTests
{
    [Fact]
    public void Soma_DeveRetornarQuatro()
    {
        Assert.Equal(4, 2 + 2);
    }

    [Fact]
    public void Subtracao_DeveRetornarDois()
    {
        Assert.Equal(2, 5 - 3);
    }
}

Você roda dotnet test — nunca chama Soma_DeveRetornarQuatro() você mesmo. É o xUnit que varre a classe por reflection, encontra métodos marcados com [Fact] e os chama um por um, decidindo ordem, capturando falhas, etc.

Compare com uma versão "biblioteca", onde você está no controle:

void RodarTestes()
{
    TestarSoma();
    TestarSubtracao();
    Console.WriteLine("tudo passou!");
}

RodarTestes();   // você chama, você decide a ordem

4. Template Method: o princípio dentro de uma única classe

public abstract class Relatorio
{
    public string Gerar()                    // o "molde" — fica no controle
    {
        var dados = BuscarDados();           // chama método que a subclasse define
        return Formatar(dados);
    }

    protected abstract List<int> BuscarDados();
    protected abstract string Formatar(List<int> dados);
}

public class RelatorioVendas : Relatorio
{
    protected override List<int> BuscarDados() => new() { 100, 200, 150 };

    protected override string Formatar(List<int> dados) => $"Total: {dados.Sum()}";
}

new RelatorioVendas().Gerar();

BuscarDados e Formatar são definidos na subclasse, mas quem os chama é o método Gerar lá na classe base. A subclasse nunca se auto-chama — ela só fornece as peças que a classe base vai encaixar quando quiser.

5. Socket cru vs. ASP.NET Core

// Baixo nível: você escreve o loop, você está no controle
var servidor = new TcpListener(IPAddress.Any, 8080);
servidor.Start();

while (true)
{
    var cliente = servidor.AcceptTcpClient();   // você chama AcceptTcpClient
    var stream = cliente.GetStream();
    var buffer = new byte[1024];
    stream.Read(buffer, 0, buffer.Length);      // você chama Read
    TratarRequisicao(buffer);                   // você chama sua própria função
}

// Framework: ASP.NET Core está no controle
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/ola", () => "Olá, mundo!");

app.Run();

A lambda passada a MapGet nunca é chamada em nenhuma linha que você escreveu. O ASP.NET Core recebe a requisição HTTP e decide chamar esse handler quando a rota /ola é acessada.

6. Injeção de dependência: o Hollywood Principle institucionalizado

public class PedidoService
{
    private readonly IPedidoRepository _repositorio;

    public PedidoService(IPedidoRepository repositorio)   // você não faz "new PedidoRepository()"
    {
        _repositorio = repositorio;                        // o container injeta a implementação
    }
}

builder.Services.AddScoped<IPedidoRepository, PedidoRepository>();

Você nunca escreve new PedidoService(new PedidoRepository()). O container de DI do ASP.NET Core resolve as dependências e chama o construtor de PedidoService por você, no momento em que a classe é necessária.

O padrão nos seis exemplos

Situação	Quem chama quem
loop manual	você chama `TratarClique`
evento (`botao.Click += ...`)	o framework/runtime chama `TratarClique`
`OrderBy(lista)` sem seletor	não há callback
`OrderBy(lista, p => p.Idade)`	`OrderBy` chama o seletor
`RodarTestes()` manual	você chama `TestarSoma`
xUnit (`[Fact]`)	o test runner chama o método de teste
classe abstrata chamando método virtual	a classe base chama, a subclasse implementa
`TcpListener` cru	você chama `AcceptTcpClient`/`Read`
ASP.NET Core (`MapGet`)	o framework chama o handler
container de DI	o container chama o construtor

Repare que isso aparece muito mais em OOP (polimorfismo, herança, interfaces) do que em programação estruturada pura — é por isso que frameworks orientados a objetos (ASP.NET Core, Spring, Angular, React) são o habitat natural do Hollywood Principle: eles dependem de você implementar um "contrato" (uma interface, uma classe abstrata, um delegate com assinatura esperada) para poderem chamá-lo de volta.

Relação com SOLID

O Hollywood Principle é primo próximo do Dependency Inversion Principle (o "D" do SOLID): módulos de alto nível não devem depender de módulos de baixo nível — ambos devem depender de abstrações. A ideia de "inverter" quem depende de quem é a mesma raiz conceitual por trás dos dois.

Vantagens e custos

Vantagem: baixo acoplamento — seu código não precisa saber os detalhes de quando ou como é chamado, só precisa implementar o contrato esperado (uma interface, um delegate, um método abstrato).

Custo: o fluxo de controle fica menos explícito. Ao ler o código isoladamente, não é óbvio quando uma função vai ser executada — isso pode dificultar o debugging, já que você precisa entender o framework para saber a ordem das chamadas. Esse "fluxo invertido" costuma ser citado como uma das razões pelas quais frameworks têm curva de aprendizado maior que bibliotecas.

Paradigma de Programação Orientada a Objetos (POO)

Yuri Peixinho — Sat, 08 Aug 2026 15:04:58 +0000

Introdução

A Programação Orientada a Objetos nasceu com a linguagem Simula 67, considerada a primeira linguagem orientada a objetos, e foi consolidada e popularizada por Smalltalk nos anos 1970. Ganhou adoção massiva na indústria com C++ e, posteriormente, Java e C#. A ideia central é organizar o código em torno de objetos: unidades que combinam dados (atributos/estado) e comportamento (métodos) em uma única estrutura.

Os quatro pilares

Encapsulamento — os dados internos de um objeto são protegidos e só podem ser acessados/alterados através de métodos expostos, escondendo detalhes de implementação do mundo externo.
Abstração — o objeto expõe apenas o que é relevante para quem o utiliza, escondendo a complexidade interna (ex.: você chama CalcularSalario() sem precisar saber como o cálculo é feito por dentro).
Herança — uma classe pode herdar atributos e métodos de outra, permitindo reaproveitamento e especialização (uma classe Desenvolvedor pode herdar de Funcionario).
Polimorfismo — objetos de classes diferentes podem responder de forma diferente ao mesmo "chamado" (o mesmo método CalcularSalario() se comporta de forma distinta para um Desenvolvedor e para um Gerente, por exemplo).

Exemplo

// Exemplo de Programação Orientada a Objetos em C#
public abstract class Funcionario
{
    public string Nome { get; }
    protected decimal SalarioBase { get; }

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

    // Abstração: cada subclasse decide como calcular seu próprio salário
    public abstract decimal CalcularSalario();
}

public class Desenvolvedor : Funcionario
{
    private int BonusPorProjeto { get; }

    public Desenvolvedor(string nome, decimal salarioBase, int bonusPorProjeto)
        : base(nome, salarioBase) // Herança
    {
        BonusPorProjeto = bonusPorProjeto;
    }

    // Polimorfismo: implementação específica do método herdado
    public override decimal CalcularSalario()
    {
        return SalarioBase + BonusPorProjeto;
    }
}

public class Gerente : Funcionario
{
    private decimal BonusPorEquipe { get; }

    public Gerente(string nome, decimal salarioBase, decimal bonusPorEquipe)
        : base(nome, salarioBase)
    {
        BonusPorEquipe = bonusPorEquipe;
    }

    public override decimal CalcularSalario()
    {
        return SalarioBase + BonusPorEquipe;
    }
}

Aqui, SalarioBase é protegido (encapsulamento), Desenvolvedor e Gerente reaproveitam a estrutura de Funcionario (herança), e cada um implementa CalcularSalario() à sua maneira (polimorfismo) — tudo isso sem que o código que consome Funcionario precise saber qual subtipo específico está manipulando.

Vantagens e limitações

Vantagens: modela bem domínios do mundo real com entidades ricas e relacionamentos complexos; favorece reuso e organização em sistemas grandes; se encaixa naturalmente em arquiteturas como Clean Architecture e DDD (Domain-Driven Design).
Limitações: hierarquias de herança profundas podem se tornar rígidas e difíceis de alterar; o estado mutável encapsulado em objetos ainda pode gerar efeitos colaterais difíceis de rastrear se mal gerenciado.

Linguagens representativas: Java, C#, Python, C++, TypeScript (com classes).

Programação Funcional

Yuri Peixinho — Sat, 08 Aug 2026 15:03:54 +0000

Introdução

A Programação Funcional tem raízes no cálculo lambda, formalizado pelo matemático Alonzo Church nos anos 1930, décadas antes da existência de computadores modernos. Sua primeira grande expressão em linguagem de programação foi o Lisp (1958), e o paradigma ganhou força prática com linguagens como Haskell, Erlang, F# e, mais recentemente, com a incorporação de recursos funcionais em linguagens multiparadigma como JavaScript, C# e Python.

Princípios centrais

Funções puras — dado o mesmo input, uma função pura sempre retorna o mesmo output, sem produzir efeitos colaterais (não altera variáveis externas, não grava em disco, não modifica o argumento recebido).
Imutabilidade — os dados não são alterados após criados; em vez de modificar uma estrutura existente, cria-se uma nova versão com a alteração aplicada.
Funções de primeira classe / funções de alta ordem — funções podem ser tratadas como qualquer outro valor: armazenadas em variáveis, passadas como argumento e retornadas por outras funções.
Composição de funções — programas são construídos combinando funções pequenas em pipelines (map, filter, reduce são os exemplos mais comuns no dia a dia).
Recursão no lugar de laços mutáveis, já que, sem estado mutável, for/while tradicionais perdem o sentido em sua forma pura.

Como não há estado compartilhado sendo alterado por múltiplas partes do código, o raciocínio sobre o comportamento do programa fica mais previsível — e a paralelização se torna muito mais segura, já que não existe o risco clássico de condições de corrida sobre uma mesma variável mutável.

Exemplo

// Exemplo de Programação Funcional em TypeScript
type Produto = { nome: string; preco: number };

const produtos: Produto[] = [
  { nome: "Notebook", preco: 3000 },
  { nome: "Mouse", preco: 50 },
  { nome: "Teclado", preco: 150 },
];

// Função de alta ordem que retorna outra função (currying)
const aplicarDesconto = (percentual: number) => (preco: number) =>
  preco * (1 - percentual);

const aplicarDesconto10 = aplicarDesconto(0.10);

// Composição via map + reduce, sem alterar "produtos"
const totalComDesconto = produtos
  .map(p => aplicarDesconto10(p.preco))
  .reduce((acumulado, precoAtual) => acumulado + precoAtual, 0);

console.log(totalComDesconto); // produtos original permanece intacto

Repare que produtos nunca é modificado — map gera um novo array, e reduce agrega esse novo array em um único valor. Essa é a essência da imutabilidade e da ausência de efeitos colaterais.

Vantagens e limitações

Vantagens: previsibilidade, testabilidade (funções puras são triviais de testar — mesmo input, mesmo output, sem mocks de estado), facilidade de paralelização/concorrência.
Limitações: pode ter uma curva de aprendizado mais alta para quem vem de um background imperativo; nem todo domínio de problema se encaixa naturalmente em transformações de dados (por exemplo, interações com I/O e efeitos colaterais são inevitáveis em algum ponto — a maioria das linguagens funcionais lida com isso através de abstrações específicas, como Monads em Haskell).

Programação Estruturada

Yuri Peixinho — Sat, 08 Aug 2026 15:03:07 +0000

Introdução

A Programação Estruturada surgiu no final dos anos 1960 e início dos anos 1970 como uma reação direta ao chamado "código espaguete" — programas repletos de saltos incondicionais (GOTO) que tornavam o fluxo de execução quase impossível de seguir. O marco histórico é o artigo de Edsger Dijkstra, "Go To Statement Considered Harmful" (1968), que propôs abandonar o GOTO em favor de estruturas de controle previsíveis.

Princípios centrais

O paradigma se apoia no Teorema da Programação Estruturada, segundo o qual qualquer algoritmo pode ser expresso combinando apenas três estruturas de controle:

Sequência — instruções executadas uma após a outra, na ordem em que aparecem.
Seleção — desvios condicionais (if/else, switch), que escolhem um caminho entre alternativas.
Repetição — laços (for, while, do-while) que repetem um bloco enquanto uma condição for satisfeita.

Além disso, o paradigma incentiva a modularização: dividir o programa em procedimentos e funções menores, cada um com uma responsabilidade clara, e o design top-down, em que o problema é refinado de uma visão geral para os detalhes de implementação.

Exemplo

csharp

// Exemplo de Programação Estruturada em C#
static decimal CalcularTotalComDesconto(decimal valorUnitario, int quantidade)
{
    decimal desconto = 0;

// Seleção
    if (quantidade >= 10)
    {
        desconto = 0.20m;
    }
    else if (quantidade >= 5)
    {
        desconto = 0.10m;
    }

    decimal total = valorUnitario * quantidade * (1 - desconto);

// Repetição
    for (int i = 1; i <= quantidade; i++)
    {
        Console.WriteLine($"Processando item{i} de{quantidade}...");
    }

    return total; // Sequência
}

Note que todo o fluxo é linear e previsível: entra-se no topo da função, cada linha executa em ordem, e as únicas variações de caminho vêm de if e for — nunca de um salto arbitrário.

Vantagens e limitações

Vantagens: legibilidade, facilidade de depuração, raciocínio linear, base sólida para qualquer outro paradigma (structured programming é praticamente universal — até código funcional e orientado a objetos usa sequência/seleção/repetição dentro de funções e métodos).
Limitações: conforme o sistema cresce, o compartilhamento de estado mutável entre muitas funções torna a manutenção difícil — problema que os paradigmas seguintes tentam resolver de formas diferentes.

Linguagens representativas: C, Pascal, Fortran (versões modernas), e qualquer linguagem no nível de suas funções/procedimentos.

Paradigmas de Programação

Yuri Peixinho — Sat, 08 Aug 2026 15:02:55 +0000

Introdução

Um paradigma de programação é uma forma de pensar e organizar a solução de um problema em código — um conjunto de princípios, conceitos e regras que orientam como o programador estrutura a lógica do software. Não se trata de uma linguagem específica, mas de uma filosofia de construção: a mesma linguagem pode suportar vários paradigmas, e o mesmo paradigma pode ser expresso em linguagens diferentes.

Uma boa analogia: pense em como se pode escrever um texto. Você pode narrar uma história cronologicamente, argumentar uma tese ponto a ponto, ou descrever uma cena através de impressões sensoriais. As palavras (a "linguagem") são as mesmas, mas a estrutura de raciocínio muda completamente. Paradigmas de programação funcionam da mesma forma: mudam a maneira como você decompõe um problema, organiza o estado dos dados e estrutura o fluxo de execução.

Visão geral: as duas grandes famílias

Historicamente, os paradigmas costumam ser agrupados em duas grandes famílias:

Imperativo — o código descreve como fazer, passo a passo, através de comandos que alteram o estado do programa (variáveis, memória). A Programação Estruturada e a Programação Orientada a Objetos derivam dessa família.
Declarativo — o código descreve o quê se quer obter, delegando o "como" para o mecanismo de execução da linguagem. A Programação Funcional é o principal representante dessa família (junto com a lógica, como Prolog, e consultas declarativas, como SQL).

Multiparadigma na Prática

Vale destacar que a maioria das linguagens modernas não obriga a escolha de um único paradigma — elas são multiparadigma. C# é um exemplo claro: seu núcleo é orientado a objetos, mas incorpora fortemente recursos funcionais através de LINQ, expressões lambda e métodos de extensão que trabalham sobre coleções imutáveis. O mesmo vale para TypeScript/JavaScript: componentes React modernos, por exemplo, tendem a favorecer funções puras e imutabilidade (hooks, useState com atualizações imutáveis) mesmo dentro de um ecossistema historicamente mais orientado a objetos.

Na prática profissional, é comum combinar os três paradigmas dentro do mesmo sistema: a estrutura geral e a modelagem de domínio seguem princípios de POO (classes, entidades, agregados), a lógica interna de cada método segue os fundamentos da programação estruturada (sequência/seleção/repetição), e transformações de dados — filtros, mapeamentos, agregações — são resolvidas de forma mais elegante e testável com um estilo funcional.

Comparando os Três Paradigmas

Aspecto	Estruturada	Funcional	Orientada a Objetos
Unidade de organização	Procedimentos/funções	Funções puras	Objetos e classes
Tratamento de estado	Mutável e compartilhado	Imutável, isolado	Encapsulado dentro do objeto
Fluxo de controle	Sequência, seleção, repetição	Composição e recursão	Troca de mensagens entre objetos
Mecanismo de reuso	Chamada de funções	Composição de funções	Herança e composição de objetos
Facilidade de paralelismo	Baixa (estado mutável)	Alta (sem efeitos colaterais)	Moderada
Melhor encaixe	Algoritmos lineares, scripts, lógica de baixo nível	Processamento/transformação de dados, sistemas concorrentes	Sistemas com domínios ricos e regras de negócio complexas
Linguagens típicas	C, Pascal	Haskell, Elixir, Clojure	Java, C#, Python

Além dos Três: Outros Paradigmas

Embora o diagrama apresentado foque nesses três pilares fundamentais, a árvore de paradigmas de programação é mais ampla. Vale citar rapidamente outras ramificações para contexto:

Programação Lógica (ex.: Prolog) — o programa é um conjunto de fatos e regras, e a execução consiste em provar consultas contra essa base de conhecimento.
Programação Orientada a Eventos — o fluxo é determinado por eventos externos (cliques, mensagens, requisições) que disparam handlers, muito comum em interfaces gráficas e sistemas reativos.
Programação Declarativa (em sentido amplo) — engloba a funcional e a lógica, mas também se manifesta em linguagens de consulta como SQL, onde se descreve o resultado desejado, não o algoritmo para obtê-lo.

Não existe um paradigma "melhor" de forma absoluta — existe o paradigma mais adequado para um problema específico, uma equipe específica e um contexto específico. A Programação Estruturada oferece a base de raciocínio linear que sustenta praticamente todo código, independentemente do paradigma "principal" escolhido. A Programação Funcional brilha em cenários de transformação de dados e concorrência, onde a previsibilidade e a ausência de efeitos colaterais reduzem bugs sutis. A Programação Orientada a Objetos se destaca na modelagem de domínios de negócio complexos, organizando entidades, comportamentos e relacionamentos de forma que espelha o mundo real.

Dominar múltiplos paradigmas — e, mais importante, saber reconhecer qual estilo de raciocínio se encaixa melhor em cada parte de um sistema — é o que diferencia um desenvolvedor que apenas escreve código funcional (no sentido de "que funciona") de um desenvolvedor que projeta software sustentável, testável e fácil de evoluir.

Cluster 4: #10 testes rápidos e independentes, #13 simplicidade e refatoração contínua

Yuri Peixinho — Sat, 01 Aug 2026 21:50:16 +0000

Introdução

Esse cluster é diferente dos outros três: ele não previne um tipo de bug, ele sustenta a capacidade de manter os outros nove princípios ao longo do tempo. A segunda lei de Lehman, a Lei da Complexidade Crescente, diz que a complexidade de um sistema aumenta por padrão a menos que alguém trabalhe ativamente para reduzir-la. Refatoração não é uma tarefa opcional de “polimento”, é a única força que contrabalança uma tendência que existe independente da sua vontade. Mas refatorar só é seguro se você consegue confirmar rapidamente que nada quebrou — e é aí que testes lentos ou dependentes de ordem matam a disciplina inteira: se rodar a suíte demora 20 minutos ou falha de forma inconsistente, o time para de rodar, para de confiar, e para de refatorar, e a lei da complexidade crescente passa a valer sem oposição. Esse não é um risco teórico: o relatório The Developer Coefficient (Stripe, 2018), baseado em pesquisa com centenas de desenvolvedores e executivos de engenharia, estimou que uma fração substancial da semana de trabalho — na casa de um terço a 40% — é perdida lidando com dívida técnica e código malfeito, com impacto econômico global estimado em centenas de bilhões de dólares por ano. Esse número é, em essência, o preço agregado de organizações que pararam de fazer #10 e #13 e deixaram a lei de Lehman correr sem freio.

#10 Testes Rápidos e Independentes

A base conceitual mais direta aqui é o acrônimo FIRST, documentado por Robert C. Martin em Clean Code (2008) e creditado a Tim Ottinger e Jeff Langr: um teste de unidade deveria ser Fast (rápido), Independent (independente de outros testes), Repeatable (repetível em qualquer ambiente), Self-Validating (retorna verdadeiro/falso, sem exigir inspeção manual de log) e Timely (escrito no momento certo, perto do código que testa). O título desse princípio no artigo pega exatamente as duas primeiras letras — porque são, na prática, as duas que mais diretamente disparam a espiral de morte descrita na introdução: um teste lento drena paciência a cada execução; um teste dependente de ordem drena confiança a cada falha que não devia ter acontecido.

Exemplo — teste lento e acoplado vs. teste rápido e isolado:

// Lento e acoplado — bate no banco de dados real a cada execução
public class RetificacaoServiceTests
{
    [Fact]
    public void DeveRetificarMovimento_QuandoValorDivergente()
    {
        var context = new FiscalDbContext(_connectionStringReal); // conexão real com SQL Server
        var service = new RetificacaoService(context);

        var resultado = service.Retificar(movimentoId: 123);

        Assert.True(resultado.Sucesso);
        // Cada execução: abre conexão de rede real, e depende de que a linha 123
        // já exista no banco com o estado "certo" — herdado de uma execução anterior
    }
}

// Rápido e isolado — dependência trocada por um fake em memória
public class RetificacaoServiceTests
{
    [Fact]
    public void DeveRetificarMovimento_QuandoValorDivergente()
    {
        var repositorioFake = new RepositorioMovimentoFake(
            new Movimento(id: 123, valor: 500m, status: StatusMovimento.Pendente));
        var service = new RetificacaoService(repositorioFake);

        var resultado = service.Retificar(movimentoId: 123);

        Assert.True(resultado.Sucesso);
        // Roda em memória, sem I/O — milissegundos. O estado de entrada é 100%
        // definido dentro do próprio teste, não herdado de nada externo
    }
}

Exemplo — teste dependente de ordem vs. independente:

// Frágil — os dois testes compartilham uma lista estática entre execuções
public class NumeracaoNotaFiscalTests
{
    private static readonly List<int> _numerosGerados = new();

    [Fact]
    public void PrimeiroNumero_DeveSerUm()
    {
        var numero = GerarProximoNumero(_numerosGerados);
        Assert.Equal(1, numero);
        _numerosGerados.Add(numero);
    }

    [Fact]
    public void SegundoNumero_DeveSerDois()
    {
        var numero = GerarProximoNumero(_numerosGerados);
        Assert.Equal(2, numero);
        // Só passa se PrimeiroNumero_DeveSerUm já rodou antes, e nessa ordem.
        // Rodar sozinho, em paralelo, ou com a suíte embaralhada: falha.
    }
}

// Independente — cada teste monta seu próprio estado, do zero
public class NumeracaoNotaFiscalTests
{
    [Fact]
    public void PrimeiroNumero_DeveSerUm()
    {
        var numero = GerarProximoNumero(new List<int>());
        Assert.Equal(1, numero);
    }

    [Fact]
    public void SegundoNumero_DeveSerDois()
    {
        var numero = GerarProximoNumero(new List<int> { 1 }); // pré-condição explícita, não herdada
        Assert.Equal(2, numero);
    }
}

O segundo exemplo é o padrão mais comum de "flakiness" na prática: dois testes que passam perfeitamente na ordem em que foram escritos, e falham de forma aparentemente aleatória assim que uma pipeline de CI paraliza a execução, ou quando algum framework de teste decide randomizar a ordem deliberadamente — justamente pra expor esse tipo de acoplamento escondido antes que ele vire um problema em produção.

#13 Simplicidade e Refatoração Contínua

A base conceitual mais direta vem de Kent Beck, em Extreme Programming Explained (1999): as Quatro Regras do Design Simples, nessa ordem de prioridade — (1) passa em todos os testes, (2) revela a intenção, (3) sem duplicação, (4) menor número de elementos possível. A ordem importa: só faz sentido buscar "menos elementos" depois de garantir que a intenção está clara e que não há duplicação — simplicidade não é sinônimo de "menos código a qualquer custo", é a ausência de tudo que não precisa estar ali.

A ligação com dívida técnica, que a introdução já traz pelo relatório da Stripe, vem de Ward Cunningham, num relato de experiência na OOPSLA de 1992: código que corta caminho pra entregar mais rápido hoje é, literalmente, um empréstimo — você recebe velocidade agora e paga juros (retrabalho, fricção, tempo de entendimento) em cada mudança futura, até que alguém pague o principal de volta via refatoração. Cunningham não estava fazendo uma crítica moral ao atalho — dívida técnica pode ser escolha racional e deliberada —, o ponto dele é que ela tem que ser paga de algum jeito, consciente ou não.

A técnica pra pagar essa dívida com segurança é formalizada por Martin Fowler em Refactoring: Improving the Design of Existing Code (1999): uma sequência de pequenas transformações, cada uma preservando o comportamento observável do sistema, verificada por testes a cada passo — nunca uma reescrita de uma vez só. Robert C. Martin resume o hábito do dia a dia nisso com a Regra do Escoteiro: deixe o código um pouco mais limpo do que você encontrou, toda vez que mexer nele — não precisa de um projeto formal de refatoração, é disciplina contínua aplicada a cada Pull Request.

Exemplo — duplicação que se acumula em silêncio:

// Complexo — a mesma validação de CPF/CNPJ duplicada em dois lugares do sistema
public class ValidadorNotaFiscal
{
    public bool Validar(NotaFiscal nota)
    {
        var doc = nota.Cliente.Documento.Replace(".", "").Replace("-", "").Replace("/", "");
        if (doc.Length == 11) { /* ~20 linhas de validação de CPF */ }
        else if (doc.Length == 14) { /* ~25 linhas de validação de CNPJ */ }
        return true;
    }
}

public class ValidadorTransmissao
{
    public bool PodeTransmitir(ArquivoEFinanceira arquivo)
    {
        var doc = arquivo.Titular.Documento.Replace(".", "").Replace("-", "").Replace("/", "");
        if (doc.Length == 11) { /* a mesma validação de CPF, copiada e colada */ }
        // quem corrigir um bug aqui precisa lembrar de corrigir no outro lugar também
    }
}

// Simples — a regra vive em um único lugar; os dois validadores delegam
public static class ValidadorDocumento
{
    public static bool EhValido(string documento)
    {
        var limpo = Limpar(documento);
        return limpo.Length switch
        {
            11 => ValidarCpf(limpo),
            14 => ValidarCnpj(limpo),
            _ => false
        };
    }

    private static string Limpar(string doc) => doc.Replace(".", "").Replace("-", "").Replace("/", "");
}

public class ValidadorNotaFiscal
{
    public bool Validar(NotaFiscal nota) => ValidadorDocumento.EhValido(nota.Cliente.Documento);
}

Essa é a Regra 3 de Beck (sem duplicação) na prática. O perigo da versão duplicada não é só o volume de código — é que um bug corrigido num lugar continua vivo no outro, esperando quieto até alguém notar a divergência, geralmente meses depois, geralmente em produção.

DEV Community: Yuri Peixinho

POO: Polimorfismo

Introdução

A ideia central do polimorfismo

Colocando pra rodar: a batalha completa

O verdadeiro poder: extensibilidade

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

Como o C# sabe qual versão rodar

POO: Herança

Introdução

Tipos de relação que herança modela

Exemplo de jogo

POO: Abstração

Introdução

Exemplo aplicado a jogo

POO: Encapsulamento

Introdução

Os dois níveis de encapsulamento

Nível de acesso em C

Erro comum

Programação Orientada a Objetos

Introdução

Pra que serve / que problema resolve

Classe vs Objeto

Por que isso importa na prática

Aprofundamentos (Visão Geral)

Livro Head First Design Pattern: Prefira composição em vez de herança

Introdução

Por que herança vira um problema

A Correção

Quando herança ainda é a escolha certa

Padrões que existem para viabilizar composição

O problema do "diamante" (bônus em linguagens com herança múltipla)

Resumo

Hollywood Principle

Introdução

Biblioteca vs. framework

Exemplos em C

1. Loop manual vs. evento

2. OrderBy com seletor: um mini-Hollywood dentro do LINQ

3. xUnit (framework de testes)

4. Template Method: o princípio dentro de uma única classe

5. Socket cru vs. ASP.NET Core

6. Injeção de dependência: o Hollywood Principle institucionalizado

O padrão nos seis exemplos

Relação com SOLID

Vantagens e custos

Paradigma de Programação Orientada a Objetos (POO)

Introdução

Os quatro pilares

Exemplo

Vantagens e limitações

Programação Funcional

Introdução

Princípios centrais

Exemplo

Vantagens e limitações

Programação Estruturada

Introdução

Princípios centrais

Exemplo

Vantagens e limitações

Paradigmas de Programação

Introdução

Visão geral: as duas grandes famílias

Multiparadigma na Prática

Comparando os Três Paradigmas

Além dos Três: Outros Paradigmas

Cluster 4: #10 testes rápidos e independentes, #13 simplicidade e refatoração contínua

Introdução

#10 Testes Rápidos e Independentes

Exemplo — teste lento e acoplado vs. teste rápido e isolado:

Exemplo — teste dependente de ordem vs. independente:

#13 Simplicidade e Refatoração Contínua

Exemplo — duplicação que se acumula em silêncio:

2. `OrderBy` com seletor: um mini-Hollywood dentro do LINQ