DEV Community: Yuri Peixinho

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

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).

DEV Community: Yuri Peixinho

POO: Scope / Visibility

Introdução

Regra prática pra decidir:

POO: Interfaces

Introdução

Interface Marcadora (marker interface)

POO: Classes Concretas

Introdução

Instanciando:

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

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