Какой уровень доступа имеют члены класса по умолчанию, если модификатор не указан? А члены интерфейса?

Уровни доступа по умолчанию в C#

В C# уровень доступа элементов зависит от контекста их объявления — находится ли элемент внутри класса, структуры, интерфейса или другого типа. Правила значительно различаются, особенно для классов и интерфейсов.

Уровень доступа членов класса по умолчанию

Для членов класса (полей, свойств, методов, событий, вложенных типов), если модификатор доступа явно не указан, применяется уровень private. Это ключевое правило инкапсуляции в объектно-ориентированном программировании на C#.

Пример:

public class MyClass
{
    int defaultField;          // private по умолчанию
    string name;               // private по умолчанию
    
    void DefaultMethod()       // private по умолчанию
    {
        // Этот метод доступен только внутри MyClass
    }

    public void PublicMethod()
    {
        defaultField = 10;     // Доступ внутри класса разрешен
        DefaultMethod();       // Доступ внутри класса разрешен
    }
}

// В другом классе
public class AnotherClass
{
    public void TestAccess()
    {
        var obj = new MyClass();
        // obj.defaultField = 5;    // Ошибка компиляции: недоступно из-за private
        // obj.DefaultMethod();     // Ошибка компиляции: недоступно из-за private
        obj.PublicMethod();        // Доступно, так как public
    }
}

Важные детали:

• Принцип сокрытия информации: private по умолчанию обеспечивает максимальную инкапсуляцию — внутренняя реализация класса скрыта от внешнего кода.
• Явность лучше неявности: Рекомендуется всегда явно указывать модификаторы доступа для улучшения читаемости кода.
• Исключение для частичных классов: В частичных классах (partial) правила остаются теми же.
• Сравнение с другими языками: В отличие от Java, где по умолчанию применяется package-private, C# использует более строгий private.

Уровень доступа членов интерфейса по умолчанию

Для членов интерфейса (методов, свойств, событий, индексаторов) ситуация принципиально иная. Члены интерфейсов по умолчанию имеют уровень доступа public, и нельзя явно указывать модификаторы доступа (кроме новых возможностей C# 8.0+).

До C# 8.0:

public interface IMyInterface
{
    void DoWork();              // Неявно public и abstract
    string Name { get; set; }   // Неявно public и abstract
    
    // private void Helper();   // Ошибка: нельзя указать модификатор доступа
}

Начиная с C# 8.0 с появлением методов по умолчанию в интерфейсах (default interface methods), появилась возможность указывать модификаторы доступа:

public interface IAdvancedInterface
{
    void PublicMethod();        // По умолчанию public (явно не указывается)
    
    // Нововведение C# 8.0:
    private void PrivateHelper() 
    {
        // Доступно только внутри интерфейса
    }
    
    protected internal void ProtectedInternalMethod();
    
    // Метод с реализацией по умолчанию
    public virtual void DefaultMethod()
    {
        PrivateHelper();  // Можно вызывать private-метод
    }
}

Ключевые правила для интерфейсов:

1. Члены без реализации: Все члены интерфейса без реализации (до C# 8.0 — все члены) неявно являются public и abstract.
2. Отсутствие явных модификаторов: До C# 8.0 явное указание любого модификатора доступа вызывало ошибку компиляции.
3. Новые возможности C# 8.0+: С введением методов по умолчанию можно использовать private, protected, internal, protected internal, public для членов с реализацией.
4. Цель интерфейса: Интерфейс определяет публичный контракт, который должны реализовывать классы, поэтому его члены по умолчанию общедоступны.

Сравнительная таблица

Рекомендации по использованию

1. Всегда указывайте модификаторы явно для членов классов — это делает код понятнее и избегает неявных поведений.
2. Помните о принципах ООП: Используйте private для сокрытия внутренней реализации, public только для API класса.
3. Для интерфейсов до C# 8.0 все члены автоматически публичные — это часть семантики контракта.
4. С C# 8.0+ интерфейсы стали более мощными, но сложными — используйте методы с реализацией осторожно.

Понимание этих правил критически важно для создания корректных, безопасных и поддерживаемых архитектур на C#, особенно при разработке библиотек и API, где контроль доступа является ключевым аспектом проектирования.