Modificadores de acesso em C#: public, private, protected e internal

Os modificadores de acesso decidem que código pode usar um tipo ou um membro. É com eles que uma classe separa a parte de que outro código depende (sua superfície pública) da parte que ela é livre para mudar (seus detalhes internos). C# tem seis deles, mais os padrões que você recebe quando não escreve nenhum.

Os seis modificadores

Um assembly é um projeto compilado: o .dll ou .exe que ele produz. "Mesmo assembly" significa "mesmo projeto", e é por isso que internal funciona como "visível para o meu código, escondido de quem usa a minha biblioteca".

private e public: encapsulamento

private é o padrão para membros e a escolha certa para a maioria dos campos. A classe expõe o que quem chama precisa por meio de métodos e propriedades public, e esses métodos mantêm os dados do objeto consistentes.

using System;

class Account
{
    private decimal balance;               // only Account can touch this
    private readonly string owner;

    public Account(string owner) { this.owner = owner; }

    public decimal Balance => balance;     // read-only view for everyone

    public void Deposit(decimal amount)
    {
        if (amount <= 0) throw new ArgumentException("Deposit must be positive");
        balance += amount;
    }

    public bool TryWithdraw(decimal amount)
    {
        if (amount > balance) return false;
        balance -= amount;
        return true;
    }

    public override string ToString() => $"{owner}: {balance}";
}

class Program
{
    static void Main()
    {
        var acc = new Account("Priya");
        acc.Deposit(300m);
        Console.WriteLine(acc.TryWithdraw(500m));
        Console.WriteLine(acc.TryWithdraw(120m));
        Console.WriteLine(acc);
        // acc.balance = 1000000m; // error CS0122: 'Account.balance' is inaccessible due to its protection level
    }
}

Saída:

False
True
Priya: 180

Como balance é privado, as únicas formas de mudá-lo são Deposit e TryWithdraw, e as duas aplicam as regras. Nenhum outro código do programa consegue criar um saldo negativo, não importa como seja escrito. É isso que o encapsulamento compra: as regras ficam em um único lugar.

private vale por tipo, não por objeto. Um método de Account pode ler other.balance em outra instância de Account, e é assim que Equals e os métodos de comparação costumam ser escritos.

protected: visível para as classes derivadas

Um membro protected fica escondido do mundo de fora, mas disponível para as classes que herdam da classe que o declara.

using System;

class Employee
{
    public string Name { get; }
    protected decimal baseSalary;

    public Employee(string name, decimal baseSalary)
    {
        Name = name;
        this.baseSalary = baseSalary;
    }

    public virtual decimal MonthlyPay() => baseSalary / 12;
}

class Manager : Employee
{
    private readonly int reports;

    public Manager(string name, decimal baseSalary, int reports) : base(name, baseSalary)
    {
        this.reports = reports;
    }

    // A derived class can read the protected field.
    public override decimal MonthlyPay() => baseSalary / 12 + reports * 100m;
}

class Program
{
    static void Main()
    {
        var staff = new Employee[]
        {
            new Employee("Sam", 48000m),
            new Manager("Rita", 72000m, 4),
        };

        foreach (var e in staff)
            Console.WriteLine($"{e.Name}: {e.MonthlyPay():F2}");

        // Console.WriteLine(staff[0].baseSalary); // error CS0122: inaccessible due to its protection level
    }
}

Saída:

Sam: 4000.00
Rita: 6400.00

Há uma regra que surpreende. Dentro de Manager, você pode usar baseSalary em this ou em outro Manager, mas não em um Employee qualquer:

class Manager : Employee
{
    public decimal Compare(Employee other)
    {
        return baseSalary - other.baseSalary;
        // error CS1540: Cannot access protected member 'Employee.baseSalary' via a qualifier
        // of type 'Employee'; the qualifier must be of type 'Manager' (or derived from it)
    }
}

O motivo: other poderia ser um Contractor que também deriva de Employee, e protected dá acesso ao seu próprio ramo da hierarquia, não ao dos seus irmãos.

Um campo protected acopla para sempre todas as classes derivadas a esse campo. Muitos códigos preferem uma propriedade ou um método protected, ou mantêm os campos privados e dão às classes derivadas só o que elas precisam.

internal: visível dentro do assembly

Membros e tipos internal podem ser usados por qualquer código do mesmo projeto e por nada fora dele. Uma biblioteca o usa para os auxiliares de que suas classes públicas dependem:

// In the MyShop.Pricing library project
public class PriceCalculator
{
    public decimal Total(Cart cart) => TaxRules.Apply(cart.Subtotal);
}

internal static class TaxRules   // callers of the library cannot see this class
{
    internal static decimal Apply(decimal amount) => amount * 1.2m;
}

Tipos de nível superior são internal quando você não escreve nenhum modificador. É por isso que uma classe que você esqueceu de marcar como public em uma biblioteca de classes "some" do projeto que a referencia.

Projetos de testes unitários são assemblies separados, então também não enxergam código internal. A solução padrão é um atributo na biblioteca:

[assembly: System.Runtime.CompilerServices.InternalsVisibleTo("MyShop.Pricing.Tests")]

protected internal e private protected

Esses dois combinam os modificadores anteriores, de formas opostas, e os nomes são fáceis de confundir:

• protected internal é protected ou internal: qualquer código no mesmo assembly, mais as classes derivadas em outros assemblies. É o mais amplo.
• private protected (C# 7.2) é protected e internal: só as classes derivadas que também estão no mesmo assembly. É o mais restrito, para uma classe base cujos pontos de extensão devem ficar dentro da sua biblioteca.

public class ReportBase
{
    protected internal string Title;      // same assembly, or subclasses anywhere
    private protected int RowLimit = 500; // subclasses in this assembly only (C# 7.2)
}

Padrões quando você não escreve nada

Ser explícito custa uma palavra e tira uma dúvida do próximo leitor, então a maioria dos guias de estilo pede o modificador mesmo quando ele é igual ao padrão.

Acesso por acessor

Uma propriedade ou um indexador pode dar a um dos acessores um modificador mais restrito que o da própria propriedade:

using System;

class Download
{
    public string File { get; }
    public int Percent { get; private set; }

    public Download(string file) { File = file; }

    public void Advance(int step)
    {
        Percent = Math.Min(100, Percent + step);
    }
}

class Program
{
    static void Main()
    {
        var d = new Download("report.pdf");
        d.Advance(40);
        d.Advance(75);
        Console.WriteLine($"{d.File}: {d.Percent}%");
        // d.Percent = 5; // error CS0272: the set accessor is inaccessible
    }
}

Saída:

report.pdf: 100%

O modificador do acessor precisa ser mais restritivo que o da propriedade, e só um dos dois acessores pode ter um.

Acessibilidade inconsistente

Um membro público não pode expor um tipo menos visível que ele mesmo, porque quem chama receberia algo que não tem permissão para nomear:

internal class Discount { }

public class Checkout
{
    public Discount Current() => null;
    // error CS0050: Inconsistent accessibility: return type 'Discount' is less accessible than method 'Checkout.Current()'
}

A mesma regra dá CS0051 para tipos de parâmetros e CS0053 para tipos de propriedades. Resolva tornando o tipo tão visível quanto o membro, ou o membro tão escondido quanto o tipo.

Escolhendo um modificador

Comece com o modificador mais restritivo que funciona e amplie-o só quando alguém precisar. Tornar algo mais visível depois é fácil e nunca quebra ninguém; tornar algo menos visível quebra todos que o usavam. Na prática: campos private, os membros que formam o propósito da classe public, auxiliares private e tipos só da biblioteca internal.