Especificadores de acesso em C++: public, private, protected

Quem pode mexer nos seus dados

Quando você escreveu sua primeira classe, provavelmente expôs todos os membros ao mundo externo. Isso funciona, mas joga fora um dos principais motivos pelos quais as classes existem: o encapsulamento - ocultar o estado interno de uma classe para que o resto do programa só possa interagir com ela por meio de uma superfície controlada. Os especificadores de acesso são como você traça essa fronteira.

Há exatamente três: public, private e protected. Cada um rotula os membros que vêm depois dele, e o rótulo decide qual código pode lê-los ou escrevê-los. Acerte isso e sua classe impõe as próprias regras; erre e qualquer bug em qualquer lugar pode corromper o estado do seu objeto.

Os três especificadores

Um especificador é uma palavra-chave seguida de dois pontos. Todo membro declarado depois dele - até o próximo especificador - fica sob aquele nível de acesso.

#include <iostream>
using namespace std;

class Account {
public:
    void deposit(double amount) { balance += amount; }  // qualquer um pode chamar
    double getBalance() const { return balance; }       // qualquer um pode ler

private:
    double balance = 0.0;   // só o próprio código de Account pode mexer nisto
};

int main() {
    Account a;
    a.deposit(100.0);
    cout << a.getBalance() << endl; // 100
    // a.balance = 999999;          // ERRO: balance é private
    return 0;
}

Descomente a última linha e o compilador se recusa a construir: balance é private, então main não pode mexer nele diretamente. É esse o objetivo - a única forma de alterar o saldo é por meio de deposit, o que significa que você pode depois adicionar validação (sem depósitos negativos, registro, limites) em um único lugar e confiar que ela é sempre aplicada.

Aqui está o detalhamento completo:

//             acessível de...
// public      qualquer lugar (qualquer código que tenha o objeto)
// private     só os membros da própria classe (+ friends)
// protected   os membros da própria classe E as classes derivadas (+ friends)

class versus struct: o padrão

Você pode escrever quantos blocos de especificadores quiser, em qualquer ordem. O que os membros recebem antes de você escrever o primeiro depende de você ter usado class ou struct:

• Em uma class, os membros são private por padrão.
• Em um struct, os membros são public por padrão.

Esse padrão é a única diferença em nível de linguagem entre as duas palavras-chave. Um struct pode ter métodos, construtores e seções private exatamente como uma class.

#include <iostream>
using namespace std;

class Locked {
    int secret = 42;   // private por padrão - nenhum especificador necessário
};

struct Open {
    int value = 7;     // public por padrão
};

int main() {
    Open o;
    o.value = 99;           // tudo bem: public
    cout << o.value << endl; // 99

    // Locked l;
    // l.secret = 1;         // ERRO: secret é private
    return 0;
}

A convenção é usar struct para meros agrupamentos de dados públicos e class quando você quer comportamento e estado oculto - mas o compilador não impõe isso, só o padrão difere.

Encapsulamento com getters e setters

O padrão do dia a dia é: os dados vão para uma seção private e um método public dá acesso controlado. Um getter somente leitura retorna o valor; um setter valida antes de atribuir. É aqui que private compensa.

#include <iostream>
using namespace std;

class Temperature {
public:
    void setCelsius(double c) {
        if (c < -273.15) {          // a física diz que não dá para ir mais baixo
            cout << "Ignoring impossible temperature\n";
            return;
        }
        celsius = c;
    }
    double getCelsius() const { return celsius; }
    double getFahrenheit() const { return celsius * 9.0 / 5.0 + 32.0; }

private:
    double celsius = 0.0;
};

int main() {
    Temperature t;
    t.setCelsius(25);
    cout << t.getCelsius() << " C = " << t.getFahrenheit() << " F\n";

    t.setCelsius(-500);             // rejeitado, o estado continua válido
    cout << t.getCelsius() << " C\n"; // ainda 25
    return 0;
}

Como celsius é private, não há como infiltrar um valor inválido - toda escrita precisa passar por setCelsius, que protege a invariante. Repare que os getters estão marcados como const: eles prometem não modificar o objeto, então você também pode chamá-los em objetos const Temperature.

protected e a herança

protected só importa quando a herança entra em cena. Ele se comporta como private para o código externo, mas uma classe derivada pode acessá-lo. Use-o para membros que uma subclasse legitimamente precisa, mas que o público ainda não deveria ter.

#include <iostream>
#include <string>
using namespace std;

class Animal {
protected:
    string name = "unknown";   // as subclasses podem usar isto...

public:
    void setName(const string& n) { name = n; }
};

class Dog : public Animal {
public:
    void speak() const {
        // 'name' é protected, então Dog pode lê-lo diretamente
        cout << name << " says Woof!\n";
    }
};

int main() {
    Dog d;
    d.setName("Rex");
    d.speak();            // Rex says Woof!
    // cout << d.name;    // ERRO: protected está fora do alcance do código externo
    return 0;
}

Um erro comum de iniciante é recorrer a protected em todo membro de dados "por via das dúvidas, caso uma subclasse precise". Isso amplia silenciosamente o contrato da sua classe - agora cada subclasse pode depender daquele campo e você não pode alterá-lo livremente. Prefira private e só promova para protected quando uma classe derivada genuinamente precisar do acesso.

A saída de emergência friend

Às vezes uma única função ou classe externa legitimamente precisa enxergar suas entranhas - um caso clássico é um operador como << que você não pode tornar membro. A palavra-chave friend concede a essa única entidade nomeada acesso aos seus membros private e protected, e a nada mais.

#include <iostream>
using namespace std;

class Point {
public:
    Point(int x, int y) : x(x), y(y) {}

    // concede a esta função específica acesso aos membros privados
    friend ostream& operator<<(ostream& os, const Point& p);

private:
    int x, y;
};

ostream& operator<<(ostream& os, const Point& p) {
    return os << "(" << p.x << ", " << p.y << ")"; // pode ler os privados x, y
}

int main() {
    Point p(3, 4);
    cout << p << endl; // (3, 4)
    return 0;
}

friend é uma exceção deliberada e cirúrgica - a própria classe nomeia exatamente em quem confia, de modo que ninguém pode se conceder acesso de fora. Use-o com parcimônia; se você se pega adicionando muitos friends, provavelmente seus membros não deveriam ter sido private para começar, ou seu projeto precisa ser repensado.

Erros comuns a evitar

• Tornar todos os membros public. Parece fácil, mas você perde toda a validação e as invariantes que o encapsulamento traz. Por padrão, dados private com métodos public.
• Esquecer o padrão de class. class Foo { int x; }; torna x private, então foo.x = 5 não vai compilar. Se você queria um simples agrupamento de dados, use struct ou adicione um rótulo public:.
• Abusar de protected. É uma fronteira mais fraca que private e só é relevante com herança. Recorrer a ele em todo lugar acopla as subclasses a campos que você talvez queira mudar.
• Esperar que private seja um recurso de segurança. É uma regra de tempo de compilação que evita acesso acidental, não criptografia. Os bytes continuam na memória; private é sobre design limpo, não sobre sigilo.

Próximo: Structs

Você já viu que um struct é, na verdade, apenas uma class cujos membros são public por padrão. A próxima página, structs, aprofunda quando esse padrão público-por-padrão é exatamente o que você quer - agregados leves para agrupar valores relacionados - e como o struct é usado no C++ idiomático ao lado de classes completas.