C# Public vs Private: When to Use Each

When you declare a member in a C# class, the first decision is often whether it should be public or private. That choice defines the boundary between the class's contract and its implementation details. In C#, public makes a member accessible from any code that can see the class, while private restricts access to the containing class only. The distinction between c# public vs private is not just a syntax rule; it directly affects how the class can evolve, how it is tested, and how safely it can be used by other code.

What Public and Private Mean in C#

In C#, access modifiers control the visibility of types and their members. For a class member, the default is private if no modifier is specified. A public member is part of the class's public API, meaning any code with a reference to the class instance can access it. A private member is only accessible from within the class itself, including its nested types.

Consider this simple class:

public class Counter
{
    public int Value { get; private set; }

    public void Increment()
    {
        Value++;
    }
}

Here, Value is publicly readable but can only be changed from inside the class. The Increment method is public, so external code can modify the counter, but it cannot set Value directly. This is a common pattern for enforcing invariants.

Encapsulation: The Reason the Distinction Matters

Encapsulation is the principle of hiding internal state and exposing only what is necessary. private is the primary tool for that. By keeping fields private, you prevent external code from putting the object into an invalid state. For example, a BankAccount class might have a private _balance field and a public Deposit method that validates the amount:

public class BankAccount
{
    private decimal _balance;

    public void Deposit(decimal amount)
    {
        if (amount <= 0)
            throw new ArgumentOutOfRangeException(nameof(amount));
        _balance += amount;
    }

    public decimal GetBalance() => _balance;
}

If _balance were public, any caller could assign a negative value or bypass the validation. The private modifier ensures that the only way to modify the balance is through the methods that enforce the rules. This is not about security in the adversarial sense; it is about preventing accidental misuse and keeping the class maintainable.

How Public and Private Affect Inheritance and Polymorphism

When a class is inherited, private members are not accessible to derived classes. They are still present in the object, but the derived class cannot see or override them. public members are inherited and can be overridden if they are marked virtual or abstract. This distinction is crucial when designing a base class.

public class Base
{
    private void Helper() { }
    public void PublicMethod() { }
}

public class Derived : Base
{
    // Cannot call Helper() here because it is private to Base.
    // PublicMethod() is accessible.
}

If you intend for derived classes to use a method, it must be protected or public. private is for implementation details that even subclasses should not touch. This prevents derived classes from depending on fragile internals, which makes the base class easier to change without breaking subclasses.

Choosing Between Public and Private in Practice

The general rule is: expose the minimum necessary API. Members that are part of the class's contract—what other code needs to interact with—should be public. Everything else should be private unless there is a specific reason to widen access.

Consider a class that parses a file. The parsing logic might be broken into several helper methods. Those helpers are implementation details and should be private. Only the entry point, say ParseFile, should be public.

public class FileParser
{
    public ParsedData Parse(string path)
    {
        var lines = ReadLines(path);
        return ParseLines(lines);
    }

    private IEnumerable<string> ReadLines(string path)
    {
        // File I/O logic
    }

    private ParsedData ParseLines(IEnumerable<string> lines)
    {
        // Parsing logic
    }
}

External callers only need to know about Parse. If later you change the parsing algorithm or the file format, you can modify the private methods without breaking the public contract. This is the core of maintainability.

Common Pitfalls and Edge Cases

One common mistake is making a field public when it should be a property with a private setter. A public field exposes the backing store directly, making it impossible to add validation or change the representation later. Prefer public properties with private setters when you need read-only access from outside.

Another edge case is nested types. A private nested type is only accessible from the containing type, which is useful for implementation details like a helper class. However, if a public method returns a private nested type, the caller cannot name the type, which can cause confusion. In such cases, consider making the nested type internal or public.

Also, note that private members are not accessible from derived classes, even if the derived class is in the same assembly. This is a common source of confusion. If you need to share members with derived classes, use protected instead.

The Role of Internal and Protected

While the question is specifically about public vs private, it is helpful to know where internal and protected fit. internal makes a member accessible within the same assembly, which is useful for testing or for sharing between classes in a library without exposing it publicly. protected allows derived classes to access the member. These are not alternatives to public and private; they are additional levels of visibility that solve specific problems.

For example, if you have a library and want to expose a method only to other classes in the same assembly but not to external consumers, internal is the right choice. If you want derived classes to use a helper method but keep it hidden from the outside, protected is appropriate.

Maintainability and API Design Considerations

The choice between public and private has a direct impact on how easily you can change the class later. Every public member becomes part of the API contract. Changing a public member's signature or removing it is a breaking change for any code that uses it. private members can be changed freely without affecting external code.

This is why it is important to start with private and only widen access when a concrete need arises. When designing a class, ask: does any external code need to call this method? If the answer is no, keep it private. If you later need to expose it, you can change it to public; that is a non-breaking addition. The reverse—changing a public member to private—is almost always a breaking change.

In large codebases, this discipline prevents the API surface from growing beyond what is necessary. It also makes unit testing easier because you can test the public behavior without depending on implementation details. If you find yourself wanting to test a private method, it is often a sign that the method should be extracted into a separate class with its own public interface, rather than making the private method public.

When Private Can Be Too Restrictive

There are cases where private is too restrictive. For example, if you have a class that is meant to be extended by users of your library, you might want to expose certain members as protected so derived classes can use them. Similarly, if you have a factory class that needs to instantiate another class, you might need internal access for the constructor.

A common pattern is the Template Method pattern, where a base class defines a skeleton algorithm and allows subclasses to override specific steps. Those steps must be protected or public (often protected). If they were private, the pattern would not work.

public abstract class DataProcessor
{
    public void Process()
    {
        ReadData();
        TransformData();
        WriteData();
    }

    protected abstract void ReadData();
    protected abstract void TransformData();
    protected abstract void WriteData();
}

Here, ReadData, TransformData, and WriteData are protected because they are meant to be overridden. They are not part of the public contract, but they are accessible to subclasses. This is a deliberate widening of visibility beyond private to support inheritance.