Почему "защищенный" модификатор в Java разрешает доступ к другим классам в одном пакете?

Ответ 1

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

Ответ 2

Модификаторы хорошо описаны в 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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

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

Подкласс может находиться вне пакета после следующих уровней объема: private < (по умолчанию) < защищенный < общественность - мы не можем сузить сферу действия. Защищенный - это более широкий охват, чем по умолчанию, поэтому Java не противоречит его собственным рекомендациям. Таким образом, защищенный член будет доступен по умолчанию. Также: class < пакет < Проект.

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