Почему в Java отсутствуют спецификаторы доступа?

Question

Кто-нибудь понимает, почему отсутствует Java:

• Спецификатор доступа, который разрешает доступ для класса и всех подклассов, но НЕ для других классов в том же пакете?(Защищено-минус)
• Спецификатор доступа, который разрешает доступ по классу, всем классам в одном пакете И всем классам в любом подпакете?(По умолчанию плюс)
• Спецификатор доступа, который добавляет классы в подпакетах к объектам, которым в настоящее время разрешен доступ защищенным?(Защищенный плюс)

Хотелось бы, чтобы у меня было больше вариантов, чем защищено и по умолчанию.В частности, меня интересует опция «Защищенный плюс».

Скажем, я хочу использовать шаблонный класс Builder / Factory для создания объекта со множеством ссылок на другие объекты.Все конструкторы объектов являются объектами по умолчанию, потому что я хочу заставить вас использовать фабричный класс для создания экземпляров, чтобы убедиться, что связывание выполнено правильно.Я хочу сгруппировать фабрики в подпакет, чтобы они были все вместе и отличались от объектов, для которых они создаются - мне это просто кажется более чистой структурой пакета.

В настоящее время это невозможно.Я должен поместить сборщиков в тот же пакет, что и объекты, которые они строят, чтобы получить доступ к настройкам по умолчанию.Но было бы неплохо отделить project.area.objects от project.area.objects.builders.

Так почему же в Java нет этих опций?И есть ли способ его подделать?

Answer 1

Кто-нибудь понимает, почему отсутствует Java:

• ...
• Спецификатор доступа, который разрешает доступ по классу, всем классам в одном пакете, Ивсе классы в любом подпакете?(По умолчанию плюс)
• Спецификатор доступа, который добавляет классы в подпакетах к объектам, которым в настоящее время разрешен доступ защищенным?(Защищенный плюс)

Пакеты Java не являются иерархическими - нет никаких подпакетов (даже если структура каталогов предполагает это).Пакеты, которые находятся «внутри» других пакетов, на самом деле не являются подпакетами, это просто пакеты, имя которых начинается с того же префикса, что и «родительский» пакет.Вы также можете увидеть это при импорте пакетов;оператор типа

import java.awt.*;

импортирует только все в пакете java.awt, а не, например, все в java.awt.image.

Таким образом, поэтому также нет спецификаторов доступа, которые работают для sub-packages.

Answer 2

Чтобы ответить на ваши вопросы по одному:

* An access specifier which allows access by the class and all subclasses, but NOT by other classes in the same package? (Protected-minus)

Это было в Java 1.0 (private protected был модификатор ) и удалено.Я не совсем понимаю, почему, но это определенно рассматривалось как нечто, не стоящее хлопот.Текущее расположение заставляет все модификаторы переходить от менее ограниченных к более ограниченным, что является более простым (как в случае с меньшим возможным изменением), что является целью разработки Java.

* An access specifier which allows access by the class, all classes in the same package, AND all classes in any sub-package? (Default-plus)

* An access specifier which adds classes in sub-packages to the entities currently allowed access by protected? (Protected-plus)

Эти два недоступны по связанной причине.В настоящее время Java не имеет понятия о подпакете, она просто притворяется тем, что обычные файловые и основанные на jar загрузчики классов (а также компилятор) следуют структуре каталогов базовой файловой системы для поиска файлов.Java будет уделять этому более широкое внимание с помощью JSR 294 («суперпакета») (как уже отмечали другие), который даст вам гораздо более детальный контроль над тем, что публикуется вне пакета (и, следовательно, вы можете сделать вещи общедоступными, если хотитек, и это все равно не будет видно).

Answer 3

Ознакомьтесь с функциями суперпакетов, которые, как сообщается, появятся в Java 7:

• Открытая дорога: Суперпакеты
• Улучшенная модульностьв Java 7

Answer 4

Предположительно, для простоты.

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

Редактировать : в проекте языка Java была определенная цель иметь простой язык , особенно в отношении C ++.Конечно, это выражается в цене выразительности;некоторые вещи сложнее сделать в Java, чем в C ++, потому что компилятор предлагает меньшую поддержку.Рассмотрим упущение const.Это делает довольно громоздким безопасное предоставление только для чтения ссылок на внутреннее состояние.Тем не менее, это также предотвращает путаницу среди начинающих из-за многочисленных ошибок компилятора, связанных с правильностью const.

Answer 5

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

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

Вам действительно нужно заставить пользователей вашего кода, чтобы иметь возможность использовать только определенные методы / конструкторы?

Разве вы не можете просто задокументировать что-то вроде «чтобы этот класс работал правильно, все экземпляры должны быть собраны с использованием этой фабрики?»и доверяете им следовать документации, которую вы им дали?

Любой, кто отклоняется от вашей документации, делает это на свой страх и риск.