Controlling Access with C# Access Modifiers and Encapsulation

Why Access Control Matters in Software Design

Access modifiers are the gatekeepers of your code. They determine which parts of your program can see and interact with the internal workings of your classes. When you build software without thoughtful access control, you create systems where any piece of code can reach into any other piece and change things it shouldn't touch. This leads to bugs that are hard to trace because the source of a problem could be anywhere in your codebase.

Think of a car's engine. You interact with it through a simple interface: the accelerator pedal, brake, and gear shift. You don't need to understand fuel injection timing or valve operations to drive. The car's designers hid those complex details behind a clean interface. This is encapsulation at work. In C#, access modifiers let you create similar boundaries in your code, exposing only what's necessary while protecting implementation details from misuse.

Throughout this guide, you'll learn how to use public, private, protected, internal, and their combinations to build maintainable applications. We'll explore real scenarios where each modifier shines, understand the trade-offs between flexibility and safety, and see how proper encapsulation makes your code easier to test, modify, and extend over time.

Public and Private: The Foundation of Encapsulation

The most fundamental distinction in access control is between public and private members. Public members form your class's contract with the outside world - they're the features you promise to provide and support. Every public member becomes part of your API surface, and changing it later might break code that depends on it. Private members, on the other hand, are your implementation details. You can refactor, rename, or completely rewrite them without affecting anyone using your class.

Consider a bank account class. The balance should be protected from direct manipulation, but you need to provide controlled ways to deposit and withdraw money. Making the balance field public would let any code set it to any value, bypassing validation and business rules. Instead, you expose public methods that enforce constraints while keeping the actual balance private.

Let's see how this principle works in practice with a proper implementation that protects its internal state while providing a clean interface:

public class BankAccount
{
    // Private field - implementation detail
    private decimal _balance;

    // Public property with controlled access
    public string AccountNumber { get; }
    public string Owner { get; }

    public BankAccount(string accountNumber, string owner)
    {
        AccountNumber = accountNumber;
        Owner = owner;
        _balance = 0;
    }

    // Public methods provide controlled access
    public void Deposit(decimal amount)
    {
        if (amount <= 0)
        {
            throw new ArgumentException(
                "Deposit amount must be positive",
                nameof(amount));
        }
        _balance += amount;
    }

    public bool Withdraw(decimal amount)
    {
        if (amount <= 0 || amount > _balance)
        {
            return false;
        }
        _balance -= amount;
        return true;
    }

    public decimal GetBalance() => _balance;
}

Notice how the balance field uses a private backing field with no direct public access. This prevents external code from setting arbitrary values like negative balances or amounts that don't match transaction records. The Deposit and Withdraw methods validate inputs and enforce business rules before modifying the balance. You can read the balance through GetBalance, but you can't bypass the validation logic to set it directly.

This pattern gives you flexibility to change how balance is stored internally. You might later decide to store transactions in a list and calculate balance on demand, or add auditing to every balance change. Because the balance field is private, you can make these changes without breaking any code that uses your BankAccount class.

Protected Access for Inheritance Scenarios

Protected members occupy a middle ground between private and public. They're invisible to external code but accessible to derived classes. This becomes important when you're building class hierarchies where subclasses need to access or override base class behavior. The protected modifier says "this is an implementation detail, but I'm allowing my children to work with it."

Use protected when you're creating extensibility points in a base class. For example, a validation framework might have a base Validator class with protected methods that derived validators can override to customize behavior. These methods shouldn't be public because they're part of the internal validation pipeline, but they need to be accessible to subclasses that extend the framework.

Here's an example showing how protected members enable safe inheritance patterns while maintaining encapsulation:

public abstract class Document
{
    // Private - completely hidden
    private readonly string _id = Guid.NewGuid().ToString();

    // Protected - available to derived classes
    protected string Content { get; set; } = string.Empty;

    // Public - the API
    public string Id => _id;
    public DateTime CreatedDate { get; }

    protected Document()
    {
        CreatedDate = DateTime.UtcNow;
    }

    // Protected virtual - can be overridden
    protected virtual bool ValidateContent()
    {
        return !string.IsNullOrWhiteSpace(Content);
    }

    // Public method uses protected validation
    public bool Save()
    {
        if (!ValidateContent())
        {
            return false;
        }
        SaveToStorage(Content);
        return true;
    }

    protected abstract void SaveToStorage(string content);
}

public class TextDocument : Document
{
    public void SetText(string text)
    {
        Content = text; // Can access protected property
    }

    // Override protected validation
    protected override bool ValidateContent()
    {
        return base.ValidateContent() &&
               Content.Length <= 10000;
    }

    protected override void SaveToStorage(string content)
    {
        File.WriteAllText($"{Id}.txt", content);
    }
}

The Content property is protected because derived classes need to work with it, but external code shouldn't have direct access. The ValidateContent method is also protected and virtual, creating an extensibility point where TextDocument adds its own validation rules while keeping the method hidden from consumers. The Id field is private with a public property, showing that even within inheritance hierarchies, some data should remain truly private to the base class.

Be cautious with protected members. Each one creates a contract with derived classes that's harder to change than private implementation details. If you make something protected, you're committing to supporting it for any future subclasses. Only use protected when you have a clear inheritance scenario that requires it.

Internal Access and Assembly Boundaries

The internal modifier restricts access to code within the same assembly (your DLL or EXE). This is incredibly useful when building libraries where you need multiple classes to work together internally, but you don't want to expose those collaboration details as part of your public API. Internal members are visible to all code in your assembly but invisible to external consumers.

Think about a data access library. You might have internal helper classes that handle connection pooling, query building, or result caching. These classes need to be accessed by your public repository classes, but they're implementation details that library consumers shouldn't depend on. Making them internal gives you freedom to refactor your internal architecture without breaking external code.

Here's a practical example of internal classes working together within a library:

// Internal helper - only visible within this assembly
internal class ConnectionPool
{
    private static readonly List _connections = new();

    internal static Connection GetConnection()
    {
        // Connection pooling logic
        return _connections.FirstOrDefault() ?? new Connection();
    }

    internal static void ReturnConnection(Connection conn)
    {
        _connections.Add(conn);
    }
}

// Public API - this is what consumers see
public class UserRepository
{
    public User GetUser(int id)
    {
        // Uses internal ConnectionPool
        var conn = ConnectionPool.GetConnection();
        try
        {
            return QueryHelper.ExecuteQuery(
                conn,
                "SELECT * FROM Users WHERE Id = @id",
                new { id });
        }
        finally
        {
            ConnectionPool.ReturnConnection(conn);
        }
    }
}

// Internal helper
internal static class QueryHelper
{
    internal static T ExecuteQuery(
        Connection conn,
        string sql,
        object parameters)
    {
        // Query execution logic
        throw new NotImplementedException();
    }
}

The ConnectionPool and QueryHelper classes are internal because they're implementation details of how UserRepository works. External code only sees the public UserRepository class and its GetUser method. You could completely rewrite how connection pooling works, switch to a different query execution strategy, or add caching layers, all without affecting any code that uses your library. The internal modifier gives you this flexibility.

You can also combine modifiers: protected internal means "accessible to derived classes OR code in the same assembly," while private protected (C# 7.2+) means "accessible to derived classes within the same assembly only." These combinations give you fine-grained control over access patterns in complex library designs.

Try It Yourself: Complete Working Example

Now let's put everything together in a complete, runnable example that demonstrates all the access modifiers in a realistic scenario. This example simulates a simple inventory management system where proper encapsulation prevents invalid states and enforces business rules.

Create a new console project and add these files to see access modifiers in action:

var inventory = new Inventory();

var item1 = new Product("Laptop", 999.99m, 10);
var item2 = new Product("Mouse", 24.99m, 50);

inventory.AddProduct(item1);
inventory.AddProduct(item2);

Console.WriteLine("Initial inventory:");
inventory.DisplayInventory();

// Try to sell products
if (inventory.SellProduct("Laptop", 3))
{
    Console.WriteLine("\nSold 3 laptops");
}

Console.WriteLine("\nUpdated inventory:");
inventory.DisplayInventory();

// This won't compile - stock is private:
// item1.stock = 100;

// This won't compile - CalculateTotalValue is internal:
// var value = inventory.CalculateTotalValue();

public class Product
{
    private decimal stock;

    public string Name { get; }
    public decimal Price { get; private set; }

    public int Stock
    {
        get => (int)stock;
        private set => stock = value;
    }

    public Product(string name, decimal price, int initialStock)
    {
        Name = name;
        Price = price;
        Stock = initialStock;
    }

    internal bool ReduceStock(int quantity)
    {
        if (quantity > Stock) return false;
        Stock -= quantity;
        return true;
    }
}

internal class Inventory
{
    private readonly List _products = new();

    public void AddProduct(Product product)
    {
        _products.Add(product);
    }

    public bool SellProduct(string name, int quantity)
    {
        var product = _products.FirstOrDefault(
            p => p.Name == name);
        return product?.ReduceStock(quantity) ?? false;
    }

    public void DisplayInventory()
    {
        foreach (var product in _products)
        {
            Console.WriteLine(
                $"{product.Name}: ${product.Price}, " +
                $"Stock: {product.Stock}");
        }
    }

    internal decimal CalculateTotalValue()
    {
        return _products.Sum(p => p.Price * p.Stock);
    }
}

Output:

Initial inventory:
Laptop: $999.99, Stock: 10
Mouse: $24.99, Stock: 50

Sold 3 laptops

Updated inventory:
Laptop: $999.99, Stock: 7
Mouse: $24.99, Stock: 50

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>
</Project>

Notice how the private stock field prevents external code from setting invalid values. The internal ReduceStock method lets the Inventory class modify stock while keeping that capability hidden from code outside the assembly. The Price property has a private setter, allowing the class to change prices internally while preventing external modifications. These access controls work together to maintain data integrity throughout the application.

Best Practices for Access Modifiers

Start with the most restrictive access level and only increase visibility when necessary. Make everything private by default, then elevate to protected, internal, or public only when you have a specific reason. This principle of least privilege prevents accidental coupling and makes your code easier to maintain. You can always make something more accessible in a future version without breaking existing code, but reducing visibility is a breaking change.

Use properties instead of public fields even when you don't need validation logic today. Properties let you add validation, computed values, or side effects later without breaking the public interface. A public field commits you to direct storage access forever, while a property gives you flexibility. Modern C# makes this easy with auto-implemented properties that have the same performance as fields.

Prefer composition over inheritance when sharing behavior. Protected members create tight coupling between base and derived classes, making both harder to modify independently. If you can achieve the same result with dependency injection or interfaces instead of inheritance, you'll often have more flexible, testable code. Reserve protected members for true "is-a" relationships where inheritance makes conceptual sense.

Be especially careful with internal members in libraries you publish. While internal gives you more freedom than public, it still creates dependencies within your assembly. Too many internal members can make refactoring difficult even when you're not constrained by external consumers. Consider whether a class really needs to be internal or if you could make it private to a namespace by using nested classes or strategic file organization.

Document your public API surface clearly. Every public or protected member represents a promise to your users. Use XML documentation comments to explain not just what a member does, but when to use it, what exceptions it might throw, and any thread safety considerations. Your public interface is a contract, and good documentation helps consumers use it correctly while giving you room to improve internal implementations.