Почему модификатор "protected" в Java разрешает доступ к другим классам в том же пакете?
В чем причина того, что в Java член с "защищенным" модификатором может быть доступен не только одному и тому же классу и подклассам, но и всем в одном и том же пакете?
Меня интересуют причины языкового дизайна, а не реальные приложения (например, тестирование)
6 ответов
Этот дизайн основан на идее, что пакет является подходящей единицей, поддерживаемой и выпущенной одной внутренне согласованной командой; Отношения наследования имеют гораздо меньшее отношение к тому, кто что поддерживает и что выпускает, когда.
Модификаторы подробно описаны по 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
Отсюда очевидна причина принятия дизайнерского решения: иметь хорошую симметричную матрицу.
В Java 1.0 был пятый модификатор доступа: private protected, Это было protected без доступа по умолчанию. По-видимому, он никогда не работал должным образом и был удален в 1.1. Так что выглядит как утверждает protected определяется таким образом, что для полного упорядочения кажется ложным. (Правка. Похоже, что по крайней мере одна из причин, по которой пятый модификатор доступа был удален в 1.1, заключалась в том, что отсутствие полного упорядочения мешало правилам выбора перегрузки.) module Модификатор доступа в Java 7 имеет несколько вопросов дизайна в этой области.
Учитывая, что считалось, что для модификатора доступа по умолчанию для членов будет хорошей идеей быть "закрытым пакетом", кажется разумным, что protected должен быть хотя бы этот уровень доступа. За мои деньги protected не платит свой путь на языке вообще.
В основном это связано с представлением пакета как контролируемого API-модуля (отсюда и рекомендация запускать ваш пакет с вашим доменным именем - гарантированная глобальная уникальность), поэтому видимость растет из private -> package-private -> protected -> public, Если бы уровень защиты не был больше, чем у закрытого пакета, а не другого типа видимости, то при необходимости должен был бы быть какой-то способ объединить два типа видимости.
Учитывая прогрессивные уровни доступа, частный, пакетный, защищенный и общедоступный, было бы излишне ограничивать, если бы он стал защищенным, тогда как пакет, так как это вынудило бы меня разрешить доступ подклассам для предоставления другим членам того же пакета. Тем не менее, интуитивно, должно быть, что другие классы в том же пакете более надежны, чем другие классы "там". Таким образом, защищенность находится между пакетом и общедоступным в том смысле, что обеспечивает более широкий доступ.
Я думаю, что основная причина заключается в интуиции, что существует базовый уровень "доверия" между классами в одном пакете; Вы можете разумно ожидать, что они будут делать правильные вещи друг с другом - в большинстве случаев за пакет будет отвечать один инженер или команда, поэтому должна быть последовательная гармония дизайна.
Ява следует своим принципам проектирования сама по себе. Что происходит, когда вы пытаетесь уменьшить / сузить область действия публичного метода в подклассе? каждый получает ошибку. Следующие уровни модификаторов области Java: private <(по умолчанию) Все классы в пакете должны быть дружелюбными, потому что они работают вместе. Чтобы сделать члена доступным в пакете, он определен в области видимости по умолчанию. Подкласс может находиться за пределами пакета, снова следующие уровни области действия: частная <(по умолчанию) <защищенная <общедоступная - мы не можем сузить область действия. Protected имеет более широкую область применения, чем по умолчанию, поэтому Java не противоречит собственным правилам. Таким образом, защищенный член будет доступен в области по умолчанию. Также: класс <пакет <проект. Пожалуйста, не ограничивайте модификаторы только видимостью, но наследование, структура также находятся в работе одновременно и добавляйте их также в изображение. Если это так: private