Java-модификаторы. Академия современного программирования

Здесь мы постараемся рассмотреть почти все случаи применения модификаторов доступа. Исключение составят лишь их применение для вложенных (nested ) и внутренних (inner ) классов, а так же для интерфейсов, так как эти темы мы еще пока не рассматривали.

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

Модификаторы доступа могут применяться как к классам, так и их членам – полям и методам. Всего существует четыре модификатора доступа и тут приведем их краткое описание, потом рассмотрим каждый подробно.

public – любой компонент, объявленный как public , доступен из любого кода
protected – разрешает доступ к компоненту в пределах пакета и классам наследникам
private – разрешает доступ к компоненты в пределах класса
по умолчанию (нет ключевого слова) – разрешает доступ к компонентам в пределах пакета

Классы наследники – это классы унаследованные от какого-либо класса. Наследование мы пока еще не изучали .

Доступ к классам

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

Доступ к членам класса

Члены класса всегда доступны внутри тела класса. По умолчанию члены класса также доступны в пакете, в котором класс определен .

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

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

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

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

Этот модификатор мы подробно рассмотрим в теме наследования классов. Если же наследование не используется, то данный модификатор работает, так же как и модификатор по умолчанию.

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

Как protected могут быть объявлены поля, методы, конструкторы, вложенные классы и вложенные интерфейсы.

protected .

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

Это самый жесткий по ограничению доступа модификатор. Элементы объявленные как private доступны только внутри этого же класса и ни кому вне класса.

Как private могут быть объявлены поля, методы, конструкторы, вложенные классы и вложенные интрефесы.

Классы и интерфейсы верхнего уровня не могут быть объявлены как private .

По существу, модификаторы доступа, это простая тема, но мы к нем еще будем возвращаться. Пока это было просто знакомство. И теперь немного практики…

Я создал классы Mod02.java, DefMod.java, ProMod.java и PrvMod.java которые принадлежат пакету pro.java.pkg002, а так же класс PubMod.java, принадлежащий пакету pro.java.pkg003. Далее приведу просто скрины этих классов и результат работы программы:

Модификаторы доступа public , private , protected

Как было рассказано ранее, наличие модификатора public перед методом или полем означает, что его можно использовать где угодно, а модификатора private - что его можно использовать только внутри данного класса. Например:

Class A { private int myValue1; public int myValue2; ... void f() { ... myValue1 = 1; // внутри класса можно использовать любое его поле myValue2 = 2; ... A a; a.myValue1; // так тоже можно... } } ... A a; a.myValue1 = 1; // ошибка компиляции - private поле a.myValue2 = 2; // public поле можно использовать везде

Рассказ о protected. Часть 1.

Если член (поле или метод) класса объявлен с модификатором protected , то он доступен не только внутри самого класса, но и внутри всех классов-наследников:

Class Base { protected int myValue; ... } class Derived extends Base { ... myValue = 1; Derived d = ...; d.myValue = 2; // это поле тоже можно использовать Base b = ...; b.myValue = 3; // ошибка компиляции ... }

protected - "прозрачное" для наследников private поле (метод). Поэтому в данном примере произойдёт ошибка, причём в независимости от того, каким объектом на самом деле является b (компилятор этого не может знать). Большинство ошибок прав доступа выявляются именно на стадии компиляции.

Этот рассказ был бы правильным, если бы в Java существовали только три модификатора прав доступа - public , private и protected - но это не совсем так.

Пакеты (Packages)

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

Когда мы до этого писали файл Main.java, мы компилировали его в той же папке, запуская компилятор строчкой javac Main.java . Но если наш файл лежит в каком-то другом каталоге (например dir1/dir2), нам нужно не просто прописать путь в командной строке, но указать это и в самом файле следующим образом:

Package dir1.dir2; // директива package может идти только первой строкой в файле public class Main { ... }

Для того, чтобы теперь скомпилировать наш Main.java мы вводим javac dir1/dir2/Main.java , при этом создается файл Main.class, лежащий в dir1/dir2. А для того, чтобы запустить наш класс, нужно ввести строку java dir1.dir2.Main (все разделители пути превращаются в точки).

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

dir1.dir2.Main называется полным именем класса (fully qualified name). При необходимости в программе можно прописывать полные имена классов:

Org.amse.np.list.List l = new org.amse.np.list.List;

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

Package org.amse.np.hw10; import org.amse.np.list.List; // импортируем класс List import org.amse.np.dllist.*; // импортируем все классы из пакета dllist (классы подкаталогов не импортируются!) class Main { ... List l = new List(); }

В любой класс всегда импортируются все классы пакета, в котором находится данный класс, и часть стандартной библиотеки Java (как если бы мы каждый раз писали в начале нашего файла строку import java.lang.*;), что позволяет использовать такие стандартные классы и методы как String , System.out.println() и т.п.

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

рекомендуется всегда использовать package
все имена package должны начинаться со строчной буквы
коммерческие организации используют пакеты, начинающиеся с com (например com.borland), остальные - с org (наример org.amse)

Однако package - это не только способ разделения на каталоги, но и важная сущность языка.

Права доступа по умолчанию

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

Таким образом, в Java есть всего четыре уровня доступа: public, private, protected и default (package local)

Рассказ о protected. Часть 2

В Java правилом является то, что у метода класса-наследника при перекрытии должны быть права не более ограничительные, чем у метода класса-родителя:

Class Base { public void f() { ... } } class Derived extends Base { private void f() { // ошибка прав доступа во время компиляции... } }

По ограничительности уровни доступа можно распределить так:

Private < protected, default < public

Если верить первой части рассказа о protected, то нельзя сказать, какой уровень доступа - protected или default - более ограничительный. Можно придумать случаи, когда будет доступно поле default и не доступно поле protected и наоборот.

Чтобы не возникало неоднозначностей с правами доступа, например при наследовании, в Java protected-уровень включает ещё и default. То есть protected член доступен всем подклассам, плюс классам внутри пакета.

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

Private < default < protected < public

Таким образом, при использовании модификатора protected мы позволяем всем классам из данного пакета иметь доступ к нашему полю/методу, что в большинстве случаев является не той ситуацией, к которой мы стремимся.

Вложенные классы

Мы рассмотрим вложенные классы лишь вскользь, как ещё один способ ограничения использования классов.

Существует два основных типа вложенных классов: static классы (nested)(?) и просто классы-члены (inner). Общий синтаксис:

Class Outer { class Inner { ... } ... }

Достаточно часто применяются вложенные private static классы:

Class List { private static class ListElement { ... } }

При компиляции класса с вложенным классом создаются два файла, в данном случае: List.class и List$ListElement.class. При этом полное имя вложенного класса будет выглядеть следующим образом: org.amse.np.list.List.ListElement

Class Outer { static class Inner { int myValue; ... } ... Inner i = new Inner(); // экземпляр вложенного класса можно создать внутри самого класса... } ... Outer.Inner i = new Outer.Inner(); // ...или снаружи

Статические вложенные классы ведут себя так же, как обычные классы, но они имеют доступ к другим статическим членам данного класса.

Нестатический вложенный класс привязан не к самому окружающему классу, а к его экземпляру, поэтому помимо всех своих полей он ещё имеет неявное поле this , указывающее на конкретный экземпляр, частью которого является вложенный класс. Такой вложенный класс имеет доступ ко всем полям и методам окружающего его класса.

Class Outer { class Inner { ... } ... Inner i = new Inner(); // создается неявное поле, куда записывается Outer.this } Outer o = ...; Inner i = o.new Inner();

Дополнение: модификаторы доступа для внешних классов

По мимо обычных внешних public классов в Java можно также создавать так называемые local классы. Они могут лежать в одном файле с public классом и являются аналогами вложенных классов.

Public class A { ... } class B { ... }

В одном файле может быть только один public класс и сколько угодно local. Файл должен называться так же, как и public класс.

Мы поговорим о модификаторах: какие бывают модификаторы, области видимости, модификаторы для классов, полей, методов. Думаю, будет не скучно.

Модификаторы в Java – это ключевые слова, которые придают классу, полю класса или методу определенные свойства.

Для обозначения видимости класса его методов и полей есть 4 модификатора доступа:

private члены класса доступны только внутри класса;
package-private или default (по умолчанию) члены класса видны внутри пакета;
protected члены класса доступны внутри пакета и в классах-наследниках;
public члены класса доступны всем.

Если Вы помните , то в конце, когда мы уже импортировали класс Cat, у нас все равно была ошибка компиляции.

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

Вы можете начать задаваться вопросом: а для чего все это нужно? Почему не сделать видимость кода из любого пакета или класса, а нужно разграничить доступ? Эти вопросы сами пропадут, когда придет время писать сложные и громоздкие проекты. Сейчас, когда мы пишем приложения, у которых функционал ограничен одним или двумя классами, то смысла что либо ограничить вроде как не видно.

Представьте, что у Вас есть класс который отображает объект некоего продукта. Например машина. У машины может быть цена. Вы создали поле цена и еще множество других полей, кучу методов которые отвечают за функционал. Все вроде хорошо. Ваш класс машина является частью огромного проекта и все довольны. Но допустим, что кто-то по ошибке или специально создал экземпляр класса автомобиль и поставил отрицательную цену. Разве может товар иметь отрицательную цену? Это очень примитивный пример и вряд ли такое может случиться в реальной жизни, но думаю, идея понятна. Иногда нужно дать доступ не напрямую, а через определенные методы. Может быть, что код отвечает за функционал другого кода, и Вы не хотите, чтобы кто-то изменял и редактировал часть Вашего. Для этого всего и есть ограничение доступа.

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

Пока об модификаторах доступа будет достаточно. В статье «Объектно ориентированное программирование» мы о них поговорим подробнее, а сейчас давайте поговорим о других модификаторах которых, к стати, немало.

Сейчас на очереди модификатор static . Его можно применять перед методом, полем и даже классом, когда хотим объявить вложенный класс. В Java можно писать классы внутри других классов и если модификатор перед классом внутри класса static, то такой класс называют вложенным, если другой модификатор или по умолчанию, то такой класс называется внутренним. О вложенных и внутренних классах будет отдельная статья, поскольку там не все так просто.

static модификатор перед методом или полем говорит о том, что они не принадлежат к экземпляру данного класса. Что это означает для нас? Когда мы описали поле класса или метод как static, его можно вызвать без использования экземпляра класса. То есть вместо такой конструкции: Cat cat = new Cat(); cat.method(), можно написать просто Cat.method(). При условии, что метод объявлен как static. Статические переменные едины для всех объектов класса. У них одна ссылка.

public class Modificators {

static int anotherStaticField = 5 ;

public static void myStaticMethod() {

someField = "My field" ;

//nonStaticField = ""; ошибка компиляции

//нельзя использовать нестатические поля

//в статических методах

public void myNonStaticMethod() {

anotherStaticField = 4 ; //ститические поля можно использовать

//в нестатических методах

//main метод тоже имеет модификатор static

new Modificators() .myNonStaticMethod () ;

Modificators.myStaticMethod () ; //вызов статических методов и полей

//через имяКласса.метод

Еще одно важное замечание, которое нужно сказать по поводу static модификаторов: статические поля инициализируются во время загрузки класса. Часто в разного рода тестах по Java можно встретить такой код:

Вопрос: что будет выведено на консоль? Нужно помнить, что static блок будет выведен первым при любом раскладе. Далее будет идти блок по умолчанию. Далее смотрите на скрин консоли:

Следующий модификатор, который мы рассмотрим будет final.

Думаю, слово final говорит само за себя. Применяя final модификатор Вы говорите, что поля не могут быть изменены, методы переопределены, а классы нельзя наследовать (о наследовании будет отдельная статья). Этот модификатор применяется только к классам, методам и переменным (также и к локальным переменным).

С модификатором final к методам и классам мы будем говорить в статье ООП.

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

Модификатор synchronized — говорит о том, что метод может быть использован только одним потоком одновременно. Хотя, возможно, это Вам ни о чем не говорит, полезность этого модификатора будет видно, когда мы будем изучать многопоточность.

Модификатор transient — говорит о том, что во время сериализации объекта некоторое поле нужно игнорировать. Как правило, такие поля хранят промежуточные значения.

Модификатор volatile — используется при многопоточности. Когда поле с модификатором volatile будет использоваться и изменяться несколькими потоками, данный модификатор гарантирует, что поле будет изменяться по очереди и путаницы с ним не возникнет.

Модификатор native перед объявлением метода указывает что метод написан на другом языке программирования. Обычно на языке C.

Модификатор strictfp — Обеспечивает выполнение операций над числами типа float и double (с плавающей запятой) по стандарту IEEE 754. Или говоря проще, гарантирует что в пределах метода результаты вычислений будут одинаковыми на всех платформах.

Я еще не говорил о модификаторе abstract . О нем скажу вкратце, так как без знаний основ объектно ориентированного программирования говорить о нем не вижу смысла.

Класс, который имеет модификатор abstract не может создать экземпляр. Единственная цель для него быть расширенным. Класс abstract может содержать как абстрактные методы, а также и обычные.

Подробнее о модификаторе abstract будем говорить в статье ООП.

На этом можно и закончить статью о модификаторах. Многое о них не было сказано. Но это из-за того, что у нас еще нет понятий ООП. Через несколько статей, мы дополним знания о модификаторах и заполним пробелы.

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.

Я видел некоторые дискуссии в 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, чтобы это сделать?

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

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

4 ответа

Сортировка:

Активность

В 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 и четко документировать тот факт, что они не должны использоваться в клиентский код.

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

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

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

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

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

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

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

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

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

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

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

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

Неявно предполагается, что все классы в пакете «знают» друг друга (потому что они были написаны одним и тем же лицом/компанией/организацией). Таким образом, они либо не получают доступа к полям 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; }

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