Почему модификатор "protected" в Java разрешает доступ к другим классам в том же пакете?

Question

В чем причина того, что в Java член с «защищенным» модификатором может быть доступен не только одному и тому же классу и подклассам, но и всем в одном пакете?

Меня интересуют причины языкового дизайна, а не реальные приложения (например, тестирование)

Answer 1

Модификаторы хорошо описаны на http://java.sun.com/docs/books/tutorial/java/javaOO/accesscontrol.html. Оттуда мы видим этот рисунок.

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

Отсюда очевидна причина, по которой принимается решение о проектировании: это хорошая симметричная матрица.

Answer 2

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

Answer 3

В Java 1.0 был пятый модификатор доступа: private protected. Это было protected без доступа по умолчанию. По-видимому, он никогда не работал должным образом и был удален в 1.1. Таким образом, похоже, заявления о том, что protected определено так, как и для общего порядка, выглядят ложными. ( Редактировать: Похоже, что по крайней мере одна из причин, по которой пятый модификатор доступа был удален в 1.1, заключалась в том, что отсутствие полного упорядочения мешало правилам выбора перегрузки.) Модификатор доступа module в Java 7 имеет несколько вопросов о дизайне в этой области.

Учитывая, что считалось, что для модификатора доступа по умолчанию для членов будет хорошей идеей быть "закрытым пакетом", представляется разумным, чтобы protected имел как минимум этот уровень доступа. За мои деньги protected вообще не платит за язык.

Answer 4

По сути, это связано с представлением пакета как контролируемого API-модуля (отсюда и рекомендация запускать пакет с вашим доменным именем - гарантированная глобальная уникальность), поэтому видимость растет из private -> package-private -> protected -> публичный. Если бы уровень защиты не превышал частный пакет, а представлял собой другой тип видимости, то при необходимости должен был бы быть какой-то способ объединить два типа видимости.

Answer 5

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

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

Answer 6

Java следует своим принципам проектирования сама по себе. Что происходит, когда вы пытаетесь уменьшить / сузить область действия публичного метода в подклассе? каждый получает ошибку. Следующие уровни модификаторов области Java: private <(по умолчанию) <protected <public </p>

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

Подкласс может находиться за пределами пакета, снова следующие уровни области действия: частная <(по умолчанию) <защищенная <общедоступная - мы не можем сузить область действия. Protected имеет более широкую область применения, чем значение по умолчанию, поэтому <strong>Java не противоречит собственным правилам . Таким образом, защищенный член будет доступен в области по умолчанию. Также: класс <пакет <проект. </p>

Пожалуйста, не ограничивайте модификаторы только видимостью, но наследование, структура также находятся в работе одновременно и добавляйте их также в изображение. Если это так: private