C# Nested Type Access Modifiers Explained

When a type is declared inside another type, its default accessibility and the range of modifiers you can apply differ from top-level types. This article explains how c# nested type access modifiers work, what each modifier means in a nested context, and where common mistakes occur.

In C#, a nested type is a type declared within the body of another type (a class or a struct). The nested type can be a class, struct, interface, enum, or delegate. The most important rule is that nested types are private by default, unlike top-level types which default to internal. This default often surprises developers because it means a nested type is not accessible from outside the containing type unless you explicitly add a modifier.

Default Accessibility and Scope

When you declare a nested type without an access modifier, it is private. That means it can only be accessed from within the containing type. For example:

public class Outer
{
    // This nested class is private by default
    class Inner
    {
    }
}

Since Inner is private, code outside Outer cannot reference it. Trying to declare a field of type Inner outside Outer produces a compile-time error. This default is consistent with the principle of encapsulation: nested types are implementation details of the containing type unless you decide to expose them.

The accessibility of a nested type cannot exceed the accessibility of its containing type. If the containing type is internal, a nested type cannot be public. The compiler enforces this rule. So a public nested type is only as accessible as its container allows. For example, a public nested class inside an internal class is effectively internal because the container itself is not accessible outside the assembly.

Applying Modifiers to Nested Types

You can apply any of the five access modifiers to a nested type: public, internal, protected, protected internal, or private protected. There is also the default private when no modifier is used. Each modifier controls which code can access the nested type name and instantiate it.

Note that protected and protected internal on a nested type are different from the same modifiers on a member. For a nested type, protected means the nested type is accessible in derived classes that inherit from the containing type. This is useful when you want to allow subclasses to use a helper type that is not part of the public API.

Using Nested Types for Encapsulation

Nested types are often used to encapsulate helper classes or data structures that are only relevant to the containing type. A common pattern is to declare a private nested class that implements a specific interface or holds state for the outer class. For example:

public class DataProcessor
{
    private readonly ILogger _logger;

    public DataProcessor(ILogger logger)
    {
        _logger = logger;
    }

    public void Process(string data)
    {
        var validator = new DataValidator(data);
        if (validator.IsValid)
        {
            // processing logic
        }
        else
        {
            _logger.Log(validator.Error);
        }
    }

    private class DataValidator
    {
        private readonly string _data;
        public bool IsValid { get; }
        public string Error { get; }

        public DataValidator(string data)
        {
            _data = data;
            // validation logic
            IsValid = true;
            Error = null;
        }
    }
}

Here, the DataValidator class is private to DataProcessor. If it were a top-level class, it would pollute the namespace and potentially be used by other code that might depend on its internal details. Keeping it private makes the public API of the assembly smaller and reduces the surface area for accidental misuse.

Another common use is to define a nested type that implements an interface that only the outer type uses. For instance:

public class Repository
{
    private readonly IQueryable<Entity> _queryable;

    public IEnumerable<Entity> GetEntities()
    {
        return _queryable.Where(e => e.IsActive).ToList();
    }
}

internal class Entity
{
    public bool IsActive { get; set; }
}

In this example, Entity is internal, but it is not nested. If the entity class were only used by Repository, declaring it as a private nested class would keep it even more hidden.

Common Misconceptions and Pitfalls

One common mistake is assuming that a nested type inherits the access modifier of its containing type. That is not the case. A nested type has its own access modifier, independent of the container. So a private nested type inside a public class is not accessible outside the class, even though the class is public.

Another pitfall is using protected on a nested type when the containing type is sealed. If the containing class is sealed, it cannot be derived, so protected and protected internal become effectively useless. The compiler may issue a warning, but the code compiles. It's better to use private or internal in that scenario.

Also, remember that a nested type has access to all private members of the containing type, including static members. This can be convenient, but it also means the nested type is tightly coupled to the outer type. If you plan to reuse the nested type elsewhere, consider making it a top-level internal type instead.

Nested Types and Inheritance

When a nested type is protected, it is visible in derived classes of the containing type. This allows derived classes to use the nested type as a base class or as a member. For example:

public class Base
{
    protected class Helper
    {
        public string GetMessage() => "Hello";
    }
}

public class Derived : Base
{
    public void DoWork()
    {
        Helper helper = new Helper();
        Console.WriteLine(helper.GetMessage());
    }
}

Here, Helper is accessible inside Derived because it inherits from Base. This pattern is useful when you want to provide a base class or interface that only derived classes should use. However, be cautious about exposing protected nested types that contain mutable state, because they become part of the inheritance contract.

Accessibility Constraints in C#

The C# compiler enforces a rule that the accessibility of a nested type cannot be broader than that of its containing type. This means:

• A public nested type cannot be declared inside an internal class.
• A protected nested type cannot be declared inside an internal class unless the containing class is also public and the method that exposes it is protected.

The compiler error CS0050 (inconsistent accessibility) is common when you try to expose a nested type through a public member. For example:

public class Outer
{
    public Inner? GetInner() => _inner;
    private Inner? _inner;
    // This is invalid because Inner is private
    // You cannot use a private type as a return type of a public method.
    private class Inner { }
}

To fix this, you would change the accessibility of Inner to public or internal (if the container is public) or make the method private. This is a frequent source of compile errors when refactoring code and changing access modifiers.

Why Encapsulation Matters for Maintainability

Nested types with proper access modifiers help maintainability in several ways. By keeping helper types private, you reduce the number of types that other parts of the codebase need to understand. This lowers cognitive load when reading the code. If a nested type is only used inside its containing type, making it private clearly communicates that it is an implementation detail.

Conversely, overusing nested types can make a class too large and hard to test. A private nested class cannot be unit-tested directly using standard public API tests. You have to test it through the outer class. If the nested type has complex logic that you want to unit test in isolation, consider extracting it to a top-level internal class and use InternalsVisibleTo to expose it to a test assembly. This allows direct testing while keeping it hidden from external consumers.

The decision between private nested and internal top-level comes down to the expected reuse. If the type is only used by one outer type, private nested is sufficient. If you foresee reuse in the same assembly, making it internal top-level is more flexible. If it needs to be exposed to other assemblies, it should be public and likely a top-level type, because a public nested type is sometimes awkward to use from outside (you have to qualify it as Outer.Inner).

Final Code Example: Access Modifiers in Action

The following example shows a realistic scenario where nested types with different modifiers are used together. A Cache class uses a private nested class for the cache entry, a protected nested class for a custom event argument that derived classes can use, and a public nested enum for configuration.

public class Cache
{
    private readonly Dictionary<string, CacheEntry> _entries = new();

    public void Add(string key, object value, DateTimeOffset expiration)
    {
        _entries[key] = new CacheEntry(value, expiration);
    }

    public object? Get(string key)
    {
        if (_entries.TryGetValue(key, out var entry) && entry.Expiration > DateTimeOffset.UtcNow)
        {
            return entry.Value;
        }
        return null;
    }

    protected class CacheEntry
    {
        public object Value { get; }
        public DateTimeOffset Expiration { get; }

        public CacheEntry(object value, DateTimeOffset expiration)
        {
            Value = value;
            Expiration = expiration;
        }
    }

    public enum CachePolicy
    {
        Sliding,
        Absolute
    }
}

In this code, CacheEntry is protected so that derived caches can access the entry details if needed. CachePolicy is public so callers can specify a policy. _entries is private and uses the private nested type CacheEntry which is not shown. This pattern keeps the cache implementation encapsulated while allowing controlled access to the cache entry structure.

Understanding c# nested type access modifiers is essential for designing clean class hierarchies and APIs. The modifier you choose should reflect how much you want to expose the nested type to the outside world. When in doubt, start with private and only increase accessibility when you have a concrete need.