Encapsulamento: Objetos que Protegem seu Estado

Nossos objetos agora têm características, nascem válidos e possuem comportamentos. Mas resta uma vulnerabilidade que enfraquece toda a robustez que construímos. Lembra da conta bancária, com seus cuidadosos métodos Depositar e Sacar que respeitam as regras (como não sacar mais do que há)? Essa proteção toda pode ser simplesmente contornada, porque a property Saldo é pública e modificável de fora: nada impede alguém de escrever conta.Saldo = 999999 diretamente, ignorando os métodos e suas verificações. É como ter um cofre com um mecanismo de segurança sofisticado na porta, mas com as paredes de papelão. Nesta aula, que fecha nossa introdução aos objetos, aprenderemos a fechar essa brecha com o encapsulamento — o pilar da orientação a objetos que consiste em esconder o estado interno de um objeto e expor apenas comportamentos seguros. É o que transforma objetos de estruturas de dados abertas em unidades genuinamente confiáveis.

A ideia: esconder o interior, expor o seguro

O encapsulamento é o princípio de que um objeto deve controlar o acesso ao seu próprio estado, escondendo os detalhes internos e permitindo que o mundo externo interaja com ele apenas por caminhos controlados e seguros. A ideia central: nem tudo dentro de um objeto precisa — ou deve — ser visível e modificável de fora. O que é interno e delicado deve ficar escondido (privado); o que o objeto oferece ao mundo como forma segura de interagir deve ficar exposto (público). Assim, o objeto se torna responsável por manter suas próprias regras, e ninguém de fora pode violá-las acidentalmente.

Uma analogia esclarece. Pense num carro. Você o dirige por uma interface simples e segura: o volante, os pedais, o câmbio. Você não mexe diretamente na injeção de combustível, na centelha das velas, na rotação do motor — esses mecanismos internos estão escondidos sob o capô, protegidos, e você interage com eles apenas indiretamente, através dos controles projetados para isso. Imagine o caos se qualquer motorista pudesse, enquanto dirige, alterar diretamente a mistura de combustível do motor: erros catastróficos seriam triviais de cometer. O carro encapsula seu funcionamento interno, expondo apenas os controles seguros. Um objeto bem projetado faz o mesmo: esconde seu maquinário interno e oferece um "painel de controle" de métodos seguros.

As ferramentas: private e public

O encapsulamento se realiza, concretamente, com os modificadores de acesso que já encontramos de passagem: private e public. Um membro (campo, property ou método) marcado como private só pode ser acessado de dentro da própria classe — é escondido do mundo externo. Um membro marcado como public pode ser acessado de qualquer lugar — é a parte exposta. A estratégia do encapsulamento é: torne privado o estado interno, e público apenas o que oferece interação segura.

Apliquemos isso à conta bancária, corrigindo a vulnerabilidade. Queremos que o saldo seja legível de fora (para consultar), mas modificável apenas pelos métodos controlados. A property Saldo ganha um set privado:

class ContaBancaria
{
    public string Titular { get; private set; }

    // Saldo: pode ser LIDO de fora (get público), mas só MODIFICADO
    // de dentro da própria classe (set privado).
    public decimal Saldo { get; private set; }

    public ContaBancaria(string titular, decimal saldoInicial)
    {
        Titular = titular;
        Saldo = saldoInicial;   // permitido: estamos DENTRO da classe
    }

    public void Depositar(decimal valor)
    {
        if (valor <= 0)
        {
            Console.WriteLine("Valor de depósito inválido.");
            return;
        }
        Saldo = Saldo + valor;   // permitido: dentro da classe
    }

    public void Sacar(decimal valor)
    {
        if (valor > Saldo)
        {
            Console.WriteLine("Saldo insuficiente.");
            return;
        }
        Saldo = Saldo - valor;   // permitido: dentro da classe
    }
}

A mudança-chave está no { get; private set; }. O get é público — qualquer um pode ler o saldo. Mas o set é privado — apenas código dentro da classe ContaBancaria pode modificar o saldo. Veja o efeito protetor:

ContaBancaria conta = new ContaBancaria("Ana", 1000m);

conta.Depositar(500m);           // OK: método público que modifica por dentro
Console.WriteLine(conta.Saldo);  // OK: leitura pública, exibe 1500

// conta.Saldo = 999999;         // ERRO DE COMPILAÇÃO: o set é privado!

A linha conta.Saldo = 999999 — a violação que antes era possível — agora nem compila. O saldo só pode ser alterado pelos métodos Depositar e Sacar, que aplicam as regras (valores positivos, saldo suficiente). A conta tornou-se genuinamente confiável: é impossível, de fora, colocá-la num estado inválido. As regras de negócio da conta estão protegidas dentro do objeto, e o único acesso é pelos caminhos seguros que ela oferece. O cofre agora tem paredes de aço, não de papelão.

Membros privados de apoio

O encapsulamento também justifica plenamente os campos privados que vimos na aula sobre properties (Aula #24). Um objeto pode ter dados e até métodos internos que são puro "maquinário" — necessários para seu funcionamento, mas que não fazem parte do que ele oferece ao mundo. Esses devem ser private. Por exemplo, uma classe poderia ter um método privado que executa um cálculo auxiliar, usado apenas internamente por seus métodos públicos:

class Termometro
{
    public double Celsius { get; private set; }

    public Termometro(double celsius) { Celsius = celsius; }

    // Método PÚBLICO: o que o objeto oferece ao mundo.
    public double EmFahrenheit()
    {
        return Converter(Celsius);   // usa o auxiliar interno
    }

    // Método PRIVADO: maquinário interno, escondido do mundo externo.
    private double Converter(double c)
    {
        return c * 9 / 5 + 32;
    }
}

O método Converter é private — ele é um detalhe de implementação, útil apenas dentro da classe, e não algo que faça sentido chamar de fora. Escondê-lo mantém a "interface pública" do objeto — aquilo que o mundo vê e usa — limpa e focada apenas no que importa: neste caso, EmFahrenheit. Essa distinção entre a interface pública (o painel de controle) e a implementação privada (o maquinário) é o coração do encapsulamento, e uma marca de bom projeto de objetos.

O princípio geral e uma síntese da fase

A regra prática do encapsulamento que você deve carregar: exponha o mínimo necessário; esconda o máximo possível. Comece tornando tudo private e torne public apenas o que o mundo externo genuinamente precisa usar. Cada coisa que você mantém privada é uma coisa que não pode ser usada errado de fora, e uma coisa que você pode mudar internamente no futuro sem afetar quem usa o objeto. Um objeto bem encapsulado é como um bom eletrodoméstico: simples e seguro de usar por fora, complexo e protegido por dentro.

Com esta aula, encerramos a introdução aos objetos, e vale olhar para o caminho percorrido nesta fase transformadora. Você partiu de valores soltos (Aula #22), aprendeu a agrupá-los em objetos definidos por classes (#23), a dar-lhes características controladas por properties (#24), a fazê-los nascer completos e válidos por construtores (#25), a dar-lhes comportamentos próprios com métodos (#26), e agora a protegê-los com encapsulamento (#27). Seus objetos são, hoje, unidades coesas, robustas e confiáveis, capazes de modelar as coisas do mundo com integridade. Essa é a grande virada anunciada lá no início da fase, agora completa.

O princípio que amarra toda a fase ficou explícito: esconder o interior e expor apenas o que é seguro usar. Com private e public, a classe passa a controlar sua própria superfície, mantendo em segredo os detalhes de implementação e oferecendo ao resto do programa apenas as operações que preservam sua coerência.

O ganho prático é duplo. O estado fica protegido contra alterações que o tornariam inválido, e a implementação fica livre para mudar sem quebrar quem usa a classe, desde que a parte pública permaneça a mesma. Encapsular não é burocracia nem desconfiança do colega: é o que permite alterar um pedaço do sistema sem auditar todos os outros.

Fontes e leituras recomendadas

• Encapsulamento em C# — a explicação oficial do pilar do encapsulamento; a base desta aula.
• Modificadores de acesso (private, public) — a referência completa dos modificadores que controlam a visibilidade.
• Properties com acessadores de acesso misto — como criar properties com get público e set privado.
• Membros privados — o significado de private e seu papel em esconder detalhes internos.
• Princípios de bom design de classes — orientações sobre projetar objetos com interfaces públicas limpas.

Exercícios

Exercício 1

Corrija a classe ContaBancaria para que o Saldo só possa ser modificado de dentro da classe (get público, set privado). Tente, de fora, atribuir diretamente um valor ao saldo (conta.Saldo = 5000) e observe o erro de compilação. Explique por que esse erro é, na verdade, uma proteção desejável.

public decimal Saldo { get; private set; }
// ... métodos Depositar e Sacar modificam Saldo internamente ...

// Fora da classe:
// conta.Saldo = 5000;   // ERRO DE COMPILAÇÃO: o set é privado

Exercício 2

Crie uma classe Cofre com uma property Conteudo (um valor decimal) que seja de leitura pública mas modificável apenas por dentro, e dois métodos públicos: Guardar(decimal valor) e Retirar(decimal valor) (que recusa retirar mais do que há). Teste os métodos e confirme que o conteúdo não pode ser alterado diretamente de fora.

class Cofre
{
    public decimal Conteudo { get; private set; }
    public Cofre() { Conteudo = 0; }
    public void Guardar(decimal valor)
    {
        if (valor > 0) Conteudo = Conteudo + valor;
    }
    public void Retirar(decimal valor)
    {
        if (valor > Conteudo) Console.WriteLine("Não há tanto no cofre.");
        else Conteudo = Conteudo - valor;
    }
}
Cofre c = new Cofre();
c.Guardar(100m);
Console.WriteLine(c.Conteudo);   // 100 (leitura permitida)
// c.Conteudo = 500;             // ERRO: set privado

Exercício 3

Explique, com suas palavras e usando a analogia do carro, o que é o encapsulamento. O que corresponde, na analogia, aos membros public e aos membros private de um objeto?

Exercício 4

Crie uma classe CalculadoraDeNota com um método público Classificar(int nota) que devolva um conceito ("Aprovado" ou "Reprovado") e um método privado auxiliar EhValida(int nota) que verifique se a nota está entre 0 e 10, usado internamente. Explique por que o método auxiliar deve ser privado.

class CalculadoraDeNota
{
    public string Classificar(int nota)
    {
        if (!EhValida(nota)) return "Nota inválida";
        return nota >= 6 ? "Aprovado" : "Reprovado";
    }
    private bool EhValida(int nota)
    {
        return nota >= 0 && nota <= 10;
    }
}

Exercício 5

Sem código: explique a regra prática "exponha o mínimo necessário; esconda o máximo possível". Por que cada membro que você mantém private traz dois benefícios — de segurança e de flexibilidade futura?