Язык программирования C#9 и платформа .NET5 - Троелсен Эндрю

В текущей главе рассматриваются только ключевые слова public и private. В последующих главах будет исследована роль модификаторов internal и protected internal (удобных при построении библиотек кода и модульных тестов) и модификатора protected (полезного при создании иерархий классов).

Использование стандартных модификаторов доступа

По умолчанию члены типов являются неявно закрытыми (private), тогда как сами типы — неявно внутренними (internal). Таким образом, следующее определение класса автоматически устанавливается как internal, а стандартный конструктор типа — как private (тем не менее, как и можно было предполагать, закрытые конструкторы классов нужны редко):

// Внутренний класс с закрытым стандартным конструктором.

class Radio

{

  Radio(){}

}

Если вы предпочитаете явное объявление, тогда можете добавить соответствующие ключевые слова без каких-либо негативных последствий (помимо дополнительных усилий по набору):

// Внутренний класс с закрытым стандартным конструктором.

internal class Radio

{

  private Radio(){}

}

Чтобы позволить другим частям программы обращаться к членам объекта, вы должны определить эти члены с ключевым словом public (или возможно с ключевым словом protected, которое объясняется в следующей главе). Вдобавок, если вы хотите открыть доступ к Radio внешним сборкам (что удобно при построении более крупных решений или библиотек кода), то к нему придется добавить модификатор public:

// Открытый класс с открытым стандартным конструктором.

public class Radio

{

  public Radio(){}

}

Использование модификаторов доступа и вложенных типов

Как упоминалось в табл. 5.1, модификаторы доступа private, protected, protected internal и private protected могут применяться к вложенному типу. Вложение типов будет подробно рассматриваться в главе 6, а пока достаточно знать, что вложенный тип — это тип, объявленный прямо внутри области видимости класса или структуры. В качестве примера ниже приведено закрытое перечисление (по имени CarColor), вложенное в открытый класс (по имени SportsCar):

(window.adrunTag = window.adrunTag || []).push({v: 1, el: 'adrun-4-390', c: 4, b: 390})

public class SportsCar

{

  // Нормально! Вложенные типы могут быть помечены как private.

  private enum CarColor

  {

    Red, Green, Blue

  }

}

Здесь допустимо применять модификатор доступа private к вложенному типу. Однако невложенные типы (вроде SportsCar) могут определяться только с модификатором public или internal. Таким образом, следующее определение класса незаконно:

// Ошибка! Невложенный тип не может быть помечен как private!

public class Radio

{

  public Radio(){}

}

Первый принцип объектно-ориентированного программирования: службы инкапсуляции C#

Концепция инкапсуляции вращается вокруг идеи о том, что данные класса не должны быть напрямую доступными через его экземпляр. Наоборот, данные класса определяются как закрытые. Если пользователь объекта желает изменить его состояние, тогда он должен делать это косвенно, используя открытые члены. Чтобы проиллюстрировать необходимость в службах инкапсуляции, предположим, что создано такое определение класса:

// Класс с единственным открытым полем.

class Book

{

  public int numberOfPages;

}

Проблема с открытыми данными заключается в том, что сами по себе они неспособны "понять", является ли присваиваемое значение допустимым с точки зрения текущих бизнес-правил системы. Как известно, верхний предел значений для типа int в C# довольно высок (2 147 483 647), поэтому компилятор разрешит следующее присваивание:

// Хм... Ничего себе мини-новелла!

Book miniNovel = new Book();

miniNovel.numberOfPages = 30_000_000;

Хотя границы типа данных int не превышены, понятно, что мини-новелла объемом 30 миллионов страниц выглядит несколько неправдоподобно. Как видите, открытые поля не предоставляют способа ограничения значений верхними (или нижними) логическими пределами. Если в системе установлено текущее бизнес-правило, которое регламентирует, что книга должна иметь от 1 до 1000 страниц, то совершенно неясно, как обеспечить его выполнение программным образом. Именно потому открытым полям обычно нет места в определениях классов производственного уровня.

На заметку! Говоря точнее, члены класса, которые представляют состояние объекта, не должны помечаться как public. В то же время позже в главе вы увидите, что вполне нормально иметь открытые константы и открытые поля, допускающие только чтение.

Инкапсуляция предлагает способ предохранения целостности данных состояния для объекта. Вместо определения открытых полей (которые могут легко привести к повреждению данных) необходимо выработать у себя привычку определять закрытые данные, управление которыми осуществляется опосредованно с применением одного из двух главных приемов: