Access level modifiers determine whether other classes can use a particular field or invoke a particular method. There are two levels of access control:

  • At the top level— public , or package-private (no explicit modifier).
  • At the member level— public , private , protected , or package-private (no explicit modifier).

A class may be declared with the modifier public , in which case that class is visible to all classes everywhere. If a class has no modifier (the default, also known as package-private ), it is visible only within its own package (packages are named groups of related classes — you will learn about them in a later lesson.)

At the member level, you can also use the public modifier or no modifier (package-private ) just as with top-level classes, and with the same meaning. For members, there are two additional access modifiers: private and protected . The private modifier specifies that the member can only be accessed in its own class. The protected modifier specifies that the member can only be accessed within its own package (as with package-private ) and, in addition, by a subclass of its class in another package.

The following table shows the access to members permitted by each modifier.

Access Levels
Modifier Class Package Subclass World
public Y Y Y Y
protected Y Y Y N
no modifier Y Y N N
private Y N N N

The first data column indicates whether the class itself has access to the member defined by the access level. As you can see, a class always has access to its own members. The second column indicates whether classes in the same package as the class (regardless of their parentage) have access to the member. The third column indicates whether subclasses of the class declared outside this package have access to the member. The fourth column indicates whether all classes have access to the member.

Access levels affect you in two ways. First, when you use classes that come from another source, such as the classes in the Java platform, access levels determine which members of those classes your own classes can use. Second, when you write a class, you need to decide what access level every member variable and every method in your class should have.

Let"s look at a collection of classes and see how access levels affect visibility. The following figure shows the four classes in this example and how they are related.

The following table shows where the members of the Alpha class are visible for each of the access modifiers that can be applied to them.

Visibility
Modifier Alpha Beta Alphasub Gamma
public Y Y Y Y
protected Y Y Y N
no modifier Y Y N N
private Y N N N

Tips on Choosing an Access Level:

If other programmers use your class, you want to ensure that errors from misuse cannot happen. Access levels can help you do this.

  • Use the most restrictive access level that makes sense for a particular member. Use private unless you have a good reason not to.
  • Avoid public fields except for constants. (Many of the examples in the tutorial use public fields. This may help to illustrate some points concisely, but is not recommended for production code.) Public fields tend to link you to a particular implementation and limit your flexibility in changing your code.

Последнее обновление: 20.04.2018

Все члены класса в языке Java - поля и методы, свойства - имеют модификаторы доступа. В прошлых темах мы уже сталкивались с модификатором public . Модификаторы доступа позволяют задать допустимую область видимости для членов класса, то есть контекст, в котором можно употреблять данную переменную или метод.

В Java используются следующие модификаторы доступа:

    public : публичный, общедоступный класс или член класса. Поля и методы, объявленные с модификатором public, видны другим классам из текущего пакета и из внешних пакетов.

    private : закрытый класс или член класса, противоположность модификатору public. Закрытый класс или член класса доступен только из кода в том же классе.

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

    Модификатор по умолчанию . Отсутствие модификатора у поля или метода класса предполагает применение к нему модификатора по умолчанию. Такие поля или методы видны всем классам в текущем пакете.

Рассмотрим модификаторы доступа на примере следующей программы:

Public class Program{ public static void main(String args) { Person kate = new Person("Kate", 32, "Baker Street", "+12334567"); kate.displayName(); // норм, метод public kate.displayAge(); // норм, метод имеет модификатор по умолчанию kate.displayPhone(); // норм, метод protected //kate.displayAddress(); // ! Ошибка, метод private System.out.println(kate.name); // норм, модификатор по умолчанию System.out.println(kate.address); // норм, модификатор public System.out.println(kate.age); // норм, модификатор protected //System.out.println(kate.phone); // ! Ошибка, модификатор private } } class Person{ String name; protected int age; public String address; private String phone; public Person(String name, int age, String address, String phone){ this.name = name; this.age = age; this.address = address; this.phone = phone; } public void displayName(){ System.out.printf("Name: %s \n", name); } void displayAge(){ System.out.printf("Age: %d \n", age); } private void displayAddress(){ System.out.printf("Address: %s \n", address); } protected void displayPhone(){ System.out.printf("Phone: %s \n", phone); }}

В данном случае оба класса расположены в одном пакете - пакете по умолчанию, поэтому в классе Program мы можем использовать все методы и переменные класса Person, которые имеют модификатор по умлчанию, public и protected. А поля и методы с модификатором private в классе Program не будут доступны.

Если бы класс Program располагался бы в другом пакете, то ему были бы доступны только поля и методы с модификатором public.

Модификатор доступа должен предшествовать остальной части определения переменной или метода.

Инкапсуляция

Казалось бы, почему бы не объявить все переменные и методы с модификатором public , чтобы они были доступны в любой точке программы вне зависимости от пакета или класса? Возьмем, например, поле age, которое представляет возраст. Если другой класс имеет прямой доступ к этому полю, то есть вероятность, что в процессе работы программы ему будет передано некорректное значение, например, отрицательное число. Подобное изменение данных не является желательным. Либо же мы хотим, чтобы некоторые данные были достуны напрямую, чтобы их можно было вывести на консоль или просто узнать их значение. В этой связи рекомендуется как можно больше ограничивать доступ к данным, чтобы защитить их от нежелательного доступа извне (как для получения значения, так и для его изменения). Использование различных модификаторов гарантирует, что данные не будут искажены или изменены не надлежащим образом. Подобное сокрытие данных внутри некоторой области видимости называется инкапсуляцией .

Так, как правило, вместо непосредственного использования полей, как правило, используют методы доступа. Например:

Public class Program{ public static void main(String args) { Person kate = new Person("Kate", 30); System.out.println(kate.getAge()); // 30 kate.setAge(33); System.out.println(kate.getAge()); // 33 kate.setAge(123450); System.out.println(kate.getAge()); // 33 } } class Person{ private String name; private int age; public Person(String name, int age){ this.name = name; this.age = age; } public String getName(){ return this.name; } public void setName(String name){ this.name = name; } public int getAge(){ return this.age; } public void setAge(int age){ if(age > 0 && age < 110) this.age = age; } }

И затем вместо непосредственной работы с полями name и age в классе Person мы будем работать с методами, которые устанавливает и возвращают значения этих полей. Методы setName, setAge и наподобие еще называют мьютейтерами (mutator), так как они изменяют значения поля. А методы getName, getAge и наподобие называют аксессерами (accessor), так как с их помощью мы получаем значение поля.

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

Привет! В сегодняшней лекции мы познакомимся с понятием «модификаторы доступа » и рассмотрим примеры работы с ними. Хотя слово «познакомимся» будет не совсем правильным: с большинством из них ты уже знаком по предыдущим лекциям. На всякий случай освежим в памяти главное. Модификаторы доступа - это чаще всего ключевые слова, которые регулируют уровень доступа к разным частям твоего кода. Почему «чаще всего»? Потому что один из них установлен по умолчанию и не обозначается ключевым словом:) Всего в Java есть четыре модификатора доступа. Перечислим их в порядке от самых строгих до самых «мягких»:

  • private;
  • protected;
  • default (package visible);
  • public.
Давай рассмотрим каждый из них, определимся, когда они могут нам пригодиться и приведем примеры:)

Модификатор private

Private - наиболее строгий модификатор доступа. Он ограничивает видимость данных и методов пределами одного класса. Этот модификатор тебе известен из лекции про геттеры и сеттеры. Помнишь этот пример? public class Cat { public String name; public int age; public int weight; public Cat (String name, int age, int weight) { this . name = name; this . age = age; this . weight = weight; } public Cat () { } public void sayMeow () { System. out. println ("Мяу!" ) ; } } public class Main { public static void main (String args) { Cat cat = new Cat () ; cat. name = "" ; cat. age = - 1000 ; cat. weight = 0 ; } } Мы рассматривали его в одном раньше. Здесь мы допустили серьезную ошибку: открыли наши данные, в результате чего коллеги-программисты получили доступ напрямую к полям класса и изменению их значения. Более того, эти значения присваивались без проверок, в результате чего в нашей программе можно создать кота с возрастом -1000 лет, именем «» и весом 0. Для решения этой проблемы мы использовали геттеры и сеттеры , а также ограничили доступ к данным с помощью модификатора private . public class Cat { private String name; private int age; private int weight; public Cat (String name, int age, int weight) { this . name = name; this . age = age; this . weight = weight; } public Cat () { } public void sayMeow () { System. out. println ("Мяу!" ) ; } public String getName () { return name; } public void setName (String name) { this . name = name; } public int getAge () { return age; } public void setAge (int age) { this . age = age; } public int getWeight () { return weight; } public void setWeight (int weight) { this . weight = weight; } } Собственно, ограничение доступа к полям и реализация геттеров-сеттеров - самый распространенный пример использования private в реальной работе. То есть реализация инкапсуляции в программе - главное предназначение этого модификатора. Это касается не только полей, кстати. Представь, что в твоей программе существует метод, который реализует какую-то ОЧЕНЬ сложную функциональность. Что бы придумать такого для примера… Скажем, твой метод readDataFromCollider() принимает на вход адрес с данными, считывает данные из Большого Адронного Коллайдера в байтовом формате, преобразует эти данные в текст, записывает в файл и распечатывает его. Даже описание метода выглядит жутковато, что уж говорить про код:) Чтобы повысить читаемость кода, было бы хорошо не писать сложную логику метода в одном месте, а наоборот - разбить функциональность на отдельные методы. Например, метод readByteData() отвечает за считывание данных, convertBytesToSymbols() конвертирует считанные с коллайдера данные в текст, saveToFile() сохраняет полученный текст в файл, а printColliderData() - распечатывает наш файл с данными. Метод readDataFromCollider() в итоге стал бы намного проще: public class ColliderUtil { public void readDataFromCollider (Path pathToData) { byte colliderData = readByteData (pathToData) ; String textData = convertBytesToSymbols (colliderData) ; File fileWithData = saveToFile (textData) ; printColliderData (fileWithData) ; } public byte readByteData (Path pathToData) { // считывает данные в байтах } public String convertBytesToSymbols (byte colliderDataInBytes) { } public File saveToFile (String colliderData) { } public void printColliderData (File fileWithColliderData) { // печатает данные из файла } } Однако, как ты помнишь из лекции про интерфейсы, пользователь получает доступ только к конечному интерфейсу. А наши 4 метода не являются его частью. Они вспомогательные : мы создали их, чтобы улучшить читаемость кода и не засовывать четыре разные задачи в один метод. Давать доступ пользователю к этим методам не нужно. Если у пользователя при работе с коллайдером появится доступ к методу convertBytesToSymbols() , он скорее всего просто не поймет, что это за метод и зачем нужен. Какие байты конвертируются? Откуда они взялись? Зачем их конвертировать в текст? Логика, которая выполняется в этом методе, не является частью интерфейса для пользователя. Только метод readDataFromCollider() - часть интерфейса. Что же делать с этими четырьмя «внутренними» методами? Правильно! Ограничить доступ к ним модификатором private . Так они смогут спокойно выполнять свою работу внутри класса и не вводить в заблуждение пользователя, которому логика каждого из них по отдельности не нужна. public class ColliderUtil { public void readDataFromCollider (Path pathToData) { byte colliderData = readByteData (pathToData) ; String textData = convertBytesToSymbols (colliderData) ; File fileWithData = saveToFile (textData) ; printColliderData (fileWithData) ; } private byte readByteData (Path pathToData) { // считывает данные в байтах } private String convertBytesToSymbols (byte colliderDataInBytes) { // конвертирует байты в символы } private File saveToFile (String colliderData) { // сохраняет считанные данные в файл } private void printColliderData (File fileWithColliderData) { // печатает данные из файла } }

Модификатор protected

Следующий по строгости модификатор доступа - protected . Поля и методы, обозначенные модификатором доступа protected , будут видны:
  • в пределах всех классов, находящихся в том же пакете, что и наш;
  • в пределах всех классов-наследников нашего класса.
Сходу трудно представить, когда это может понадобиться. Не удивляйся: случаев применения protected гораздо меньше, чем private , и они специфические. Представь, что у нас есть абстрактный класс AbstractSecretAgent , обозначающий секретного агента какой-то спецслужбы, а также пакет top_secret , в котором лежит этот класс и его наследники. От него наследуются конкретные классы - FBISecretAgent , MI6SecretAgent , MossadSecretAgent и т.п. Внутри абстрактного класса мы хотим реализовать счетчик агентов. При создании где-то в программе нового объекта-агента он будет увеличиваться. package top_secret; public abstract class AbstractSecretAgent { public static int agentCount = 0 ; } Но агенты-то у нас секретные! А значит, об их числе должны знать только они и никто другой. Мы легко можем добавить модификатор protected к полю agent_counter , и тогда получить его значение смогут либо объекты других классов секретных агентов, либо те классы, которые расположены в нашем «секретном» пакете top_secret . public abstract class AbstractSecretAgent { protected static int agent_counter = 0 ; } Вот для таких специфических задач и нужен модификатор protected:)

Модификатор package visible

Дальше у нас по списку идет модификатор default или, как его еще называют, package visible . Он не обозначается ключевым словом, поскольку установлен в Java по умолчанию для всех полей и методов. Если написать в твоем коде - int x = 10 … у переменной x будет этот самый package visible доступ. Запомнить, что он делает, легко. По сути, default = protected -наследование:) Случаи его применения ограничены, как и у модификатора protected . Чаще всего default -доступ используется в пакете, где есть какие-то классы-утилиты, не реализующие функциональность всех остальных классов в этом пакете. Приведем пример. Представь, что у нас есть пакет «services ». Внутри него лежат различные классы, которые работают с базой данных. Например, есть класс UserService , считывающий данные пользователей из БД, класс CarService , считывающий из этой же БД данные об автомобилях, и другие классы, каждый из которых работает со своим типом объектов и читает данные о них из базы. package services; public class UserService { } package services; public class CarService { } Однако легко может случиться ситуация, когда данные в базе данных лежат в одном формате, а нам они нужны в другом. Представь, что дата рождения пользователя в БД хранится в формате TIMESTAMP WITH TIME ZONE... 2014 - 04 - 04 20 : 32 : 59.390583 + 02 ...нам вместо этого нужен самый простой объект - java.util.Date . Для этой цели можем создать внутри пакета services специальный класс Mapper . Он будет отвечать за конвертацию данных из базы в привычные нам Java-объекты. Простой вспомогательный класс. Обычно мы создаем все классы как public class ClassName , но это не обязательно. Мы можем объявить наш вспомогательный класс просто как class Mapper . В таком случае он все равно делает свою работу, но не виден никому за пределами пакета services ! package services; class Mapper { } package services; public class CarService { Mapper mapper; } А это, по сути, правильная логика: зачем кому-то за пределами пакета видеть вспомогательный класс, работающий только с классами этого же пакета?

Модификатор public

И последний по списку, но не по значимости - модификатор public ! С ним ты познакомился в первый день учебы на JavaRush, впервые в жизни запустив public static void main(String args) . Теперь, когда ты изучил лекции об интерфейсах, для тебя очевидно его предназначение:) Ведь public создан для того, чтобы отдавать что-то пользователям. Например, интерфейс твоей программы. Допустим, ты написал программу-переводчик, и она умеет переводить русский текст в английский. Ты создал метод translate(String textInRussian) , внутри которого реализована необходимая логика. Этот метод ты отметил словом public , и теперь он станет частью интерфейса: public class Translator { public String translate (String textInRussian) { // переводит текст с русского на английский } } Можно связать вызов этого метода с кнопкой «перевести» на экране программы - и все! Кто угодно может этим пользоваться. Части кода, помеченные модификатором public , предназначаются для конечного пользователя. Если привести пример из жизни, private - это все процессы, происходящие внутри телевизора, когда он работает, а public - это кнопки на пульте телевизора, с помощью которых пользователь может им управлять. При этом ему не нужно знать как устроен телевизор и за счет чего он работает. Пульт - это набор public -методов: on() , off() , nextChannel() , previousChannel() , increaseVolume() , decreaseVolume() и т.д.

5

Я видел некоторые дискуссии в StackOverflow об этой теме, но я не вижу что-то, что помогло мне понять следующий пункт:

я происхожу из C++ фона и в последнее время Я начал изучать Java. В C++, когда защищен , используется только подкласс, который может получить доступ к члену (аналог поля в Java).

В C++ есть также классы «друг», которые могут иметь доступ к частным/защищенным камерам класса, которые дают «дружбу». Это немного похоже на модификатор поля «package» в Java (модификатор поля по умолчанию), за исключением того, что в C++ дружба дает доступ ко всем закрытым членам, но в Java доступ из классов в одном пакете специфичен для поля класса,

Что я не могу понять, предполагая, что хочу предоставить доступ только к подклассам, это то, что я могу сделать на C++, объявив членов, защищенных в классе, который не «дает» дружеские отношения.

Но на Java я не знаю, как это сделать, поскольку с помощью «защищенного» модификатора поля - я также предоставляю доступ ко всем классам в пакете. Единственный способ, которым я нахожу это, - объявить защищенное поле и изолировать класс в своем пакете.

Отсюда я заключаю, что группировка классов в один пакет должна выполняться на основе «дружбы» между классами. Действительно ли это является ведущим фактором при группировании пакетов?

Еще одна вещь, которую я не понимаю, В Java, предполагая, что у меня есть два поля в классе A: b, c. Я хочу дать B доступ к b, но не к, и я хочу дать C доступ к c, но не b. и к «Миру» я хочу b, c, чтобы скрыть. Как это можно сделать? Я предполагаю, что B, C должны быть в том же пакете, что и A. , но путем объявления b, c с пакетом модификатором Я разрешаю B, C доступ как к b, так и к. Есть ли способ в Java, чтобы это сделать?

Надежда для некоторого объяснения этого вопроса

11

Лучший вопрос, если менее полезным для вас будет более узким и конкретным. Общий вопрос «все о конфиденциальности в Java и C++ и о том, как они отличаются», более чем слишком широк. Можете ли вы задать более конкретный вопрос о более конкретной проблеме? - Yakk 04 мар. 15 2015-03-04 16:38:58

  • 4 ответа

    • Сортировка:

    Активность

2

В C++, когда используется защита, только подкласс может получить доступ к элементу (аналог поля в Java).

Спецификаторы доступа также предназначены для функций-членов/методов, а не только для переменных-членов.

В C++ есть также «друг» классы, которые могут иметь доступ к частным/защищаемому mambers класса, что дает «дружбу». Этот немного похож на модификатор поля «package» в Java (по умолчанию модификатор поля), за исключением того, что в C++ дружба дает доступ ко всем частным членам, но в Java доступ из классов в том же пакете специфичен для поле класса.

Существует не только friend классы, но и функции.

Верно, что доступ к частным частям Java аналогичен, но это не полная замена. Лучше сказать, что эти две функции имеют подмножество проблем, которые они решают. Есть проблемы, которые могут быть решены friend , но не пакетом-частным, и наоборот.

То, что я не мог понять, если предположить, что я хочу, чтобы предоставить доступ только к подклассам, это то, что я могу сделать в C++, объявив пользователей защищенных в классе, который не «дает» дружба.

Но в Java, я не знаю, как я могу это сделать,

Ответ: Вы не можете.

так как с помощью «защищенного» модификатора поля - я также предоставляю доступ к всем классам в пакете.

Единственный способ, которым я нахожу, это объявить защищенное поле и иметь класс, изолированный в его пакете.

Технически, да. Но это создает другие проблемы. Ваш класс больше не сможет получить доступ к частным частям пакета своего предыдущего пакета. Допустим, ваш BaseClass был в com.example.one . Вы переместите его на com.example.two . Теперь он больше не сможет получить доступ к другим пакетам-частным классам com.example.one .

Действительно ли это является ведущим фактором при группировании пакетов?

Да, Java спроектирован таким образом. Вы можете попробовать бороться с правилами языка , но это проигрышная битва на любом языке программирования.

Еще одна вещь, которую я не понимаю, в Java, предполагая, что у меня есть два поля в классе A: b, c. Я хочу дать B доступ к b, но не к, и я хочу предоставить C доступ к c, но не b. и в «Мир» я хочу b, c , чтобы скрыть. Как это можно сделать?

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

Если вы обеспокоены этим сценарием, поскольку вы разрабатываете публичный API, низкотехнологичное решение, которое обычно прекрасно работает, - это создать один или несколько пакетов *.internal и четко документировать тот факт, что они не должны использоваться в клиентский код.

1

Это довольно куча вопросов вместе...

Но в Java, я не знаю, как я могу это сделать, так как в силу используя «защищенный» модификатор поля - я также предоставляю доступ ко всем классам в пакете.

Действительно, нет способа предоставить доступ только к подклассам, но не к классам в одном пакете. Это было дизайнерское решение, принятое много веков назад...

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

Это технически правильно, хотя это будет мало использовать. Упаковка классов предназначена для группировки связанных классов, где «родственные» означает «классы, которые выполняют конкретное отношение», т. Е. Они принадлежат одному и тому же варианту использования, принадлежат к одному и тому же архитектурному уровню, находятся в одной и той же сущности, и т.д.

Отсюда я заключаю, что группировка классов в один пакет должна выполняться на основе «дружбы» между классами. Действительно ли это является ведущим фактором при группировании пакетов?

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

Для вашего A, B и C классов, например, с атрибутами:

Я думаю, B, C должно быть как в том же пакете, А. а объявляющего б, с модификатором упаковки I пусть В, C доступ как к b, так и к. Есть ли способ в Java сделать это?

Ответ нет, нет простого и чистого способа сделать это. Вы могли бы добиться этого с помощью некоторых хаков или более продвинутых техник, но, опять же, это было частью решений, принятых разработчиками языка давным-давно...

0

Короткий ответ: нет никакого способа сделать это.

Если вы беспокоитесь о вторжении от клиентов инъекционного класса в пакете, чтобы получить несанкционированный доступ, вы можете перемещать чувствительный код в отдельном пакете, и сделать пакет запечатанного в банке вы доставить его в: http://docs.oracle.com/javase/tutorial/deployment/jar/sealman.html

1

Неявно предполагается, что все классы в пакете «знают» друг друга (потому что они были написаны одним и тем же лицом/компанией/организацией). Таким образом, они либо не получают доступа к полям protected , либо, если они это делают, они знают, как это сделать должным образом.

Предполагается, что классы в одном пакете более связаны друг с другом, чем родительский, с производным классом, потому что производный класс может быть фактически написан кем-либо еще. Поэтому они решили, что частная защита более ограничена, чем защищена.

Итак, я думаю, вам не стоит беспокоиться о том, как классы в одном пакете могут обращаться к полям друг друга. В общем, я просто не использую эту функцию, за исключением случаев, когда я пишу итераторы.

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

Конечно, вы можете придумать сложный протокол обмена токенами, чтобы сделать это поле доступным только для экземпляров B/C, но это было бы замечательным накладным расходами, а другой объект все равно может использовать отражение, чтобы получить доступ ко всем частным членов, если вы не отключите его с помощью политик безопасности, что обычно не так, но опять же, политики безопасности в конечном итоге решаются владельцем JVM.

Итак, в конечном итоге предпочтительный способ сделать то, что вы говорите на Java, - либо поместить их в один и тот же пакет, либо написать B и C как внутренние классы A, чтобы они могли напрямую обращаться к закрытым членам A и подвергать их их производным классам.

Public class A { public static abstract class B { protected Whatever getWhatever(A a) { return a.b; } protected void setWhatever(A a, Whatever value) { a.b = value; } } public static abstract class C { protected Whatever getWhatever(A a) { return a.c; } protected void setWhatever(A a, Whatever value) { a.c = value; } } private Whatever b; private Whatever c; }

еще раз, вы всегда считаете, что классы в одном пакете никогда не сделают ничего плохого.

Последнее обновление: 13.01.2018

Все члены класса - поля, методы, свойства - все они имеют модификаторы доступа . Модификаторы доступа позволяют задать допустимую область видимости для членов класса. То есть контекст, в котором можно употреблять данную переменную или метод. В предыдущей теме мы уже с ними сталкивались, когда объявляли поля класса Book публичными (то есть с модификатором public).

В C# применяются следующие модификаторы доступа:

    public : публичный, общедоступный класс или член класса. Такой член класса доступен из любого места в коде, а также из других программ и сборок.

    private : закрытый класс или член класса. Представляет полную противоположность модификатору public. Такой закрытый класс или член класса доступен только из кода в том же классе или контексте.

    protected : такой член класса доступен из любого места в текущем классе или в производных классах. При этом производные классы могут располагаться в других сборках.

    internal : класс и члены класса с подобным модификатором доступны из любого места кода в той же сборке, однако он недоступен для других программ и сборок (как в случае с модификатором public).

    protected internal : совмещает функционал двух модификаторов. Классы и члены класса с таким модификатором доступны из текущей сборки и из производных классов.

    private protected : такой член класса доступен из любого места в текущем классе или в производных классах, которые определены в той же сборке.

Объявление полей класса без модификатора доступа равнозначно их объявлению с модификатором private . Классы, объявленные без модификатора, по умолчанию имеют доступ internal .

Все классы и структуры, определенные напрямую в пространствах имен и не являющиеся вложенными в другие классы, могут иметь только модификаторы public или internal.

Посмотрим на примере и создадим следующий класс State:

Public class State { int a; // все равно, что private int a; private int b; // поле доступно только из текущего класса protected int c; // доступно из текущего класса и производных классов internal int d; // доступно в любом месте программы protected internal int e; // доступно в любом месте программы и из классов-наследников public int f; // доступно в любом месте программы, а также для других программ и сборок protected private int g; // доступно из текущего класса и производных классов, которые определены в том же проекте private void Display_f() { Console.WriteLine($"Переменная f = {f}"); } public void Display_a() { Console.WriteLine($"Переменная a = {a}"); } internal void Display_b() { Console.WriteLine($"Переменная b = {b}"); } protected void Display_e() { Console.WriteLine($"Переменная e = {e}"); } }

Так как класс State объявлен с модификатором public , он будет доступен из любого места программы, а также из других программ и сборок. Класс State имеет пять полей для каждого уровня доступа. Плюс одна переменная без модификатора, которая является закрытой по умолчанию.

Также имеются четыре метода, которые будут выводить значения полей класса на экран. Обратите внимание, что так как все модификаторы позволяют использовать члены класса внутри данного класса, то и все переменные класса, в том числе закрытые, у нас доступны всем его методам, так как все находятся в контексте класса State.

Теперь посмотрим, как мы сможем использовать переменные нашего класса в программе (то есть в методе Main класса Program):

Class Program { static void Main(string args) { State state1 = new State(); // присвоить значение переменной a у нас не получится, // так как она закрытая и класс Program ее не видит // И данную строку среда подчеркнет как неправильную state1.a = 4; //Ошибка, получить доступ нельзя // то же самое относится и к переменной b state1.b = 3; // Ошибка, получить доступ нельзя // присвоить значение переменной с то же не получится, // так как класс Program не является классом-наследником класса State state1.c = 1; // Ошибка, получить доступ нельзя // переменная d с модификатором internal доступна из любого места программы // поэтому спокойно присваиваем ей значение state1.d = 5; // переменная e так же доступна из любого места программы state1.e = 8; // переменная f общедоступна state1.f = 8; // Попробуем вывести значения переменных // Так как этот метод объявлен как private, мы можем использовать его только внутри класса State state1.Display_f() ; // Ошибка, получить доступ нельзя // Так как этот метод объявлен как protected, а класс Program не является наследником класса State state1.Display_e(); // Ошибка, получить доступ нельзя // Общедоступный метод state1.Display_a(); // Метод доступен из любого места программы state1.Display_b(); Console.ReadLine(); } }

Таким образом, мы смогли установить только переменные d, e и f, так как их модификаторы позволяют использовать в данном контексте. И нам оказались доступны только два метода: state1.Display_a() и state1.Display_b(). Однако, так как значения переменных a и b не были установлены, то эти методы выведут нули, так как значение переменных типа int по умолчанию инициализируются нулями.

Несмотря на то, что модификаторы public и internal похожи по своему действию, но они имеют большое отличие. Классы и члены класса с модификатором public также будут доступны и другим программам, если данных класс поместить в динамическую библиотеку dll и потом ее использовать в этих программах.

Благодаря такой системе модификаторов доступа можно скрывать некоторые моменты реализации класса от других частей программы. Такое сокрытие называется инкапсуляцией .