Почему делает “защищенный” модификатор в Java, предоставляют доступ к другим классам в том же пакете?
Вы говорите, что вы не хотите генерировать случайные цвета, вы говорите, что хотите генерировать разные цвета.
Вы можете найти хороший учебник о том, как это сделать, здесь: http://krazydad.com/tutorials/makecolors.php .
Я сделал эту скрипку с соответствующим кодом из учебника демонстрируя, как вы будете генерировать неповторяющиеся цвета:
Единственное отличие от учебного кода состоит в том, что makegradient ( ) функция возвращает массив цветов, которые вы можете позже применить по желанию на своей странице.
5 ответов
Этот дизайн основан на идее, что пакет является подходящей единицей, поддерживаемой и выпускаемой одной внутренне согласованной командой; Отношения наследования имеют гораздо меньшее отношение к тому, кто что и когда поддерживает и выпускает.
Модификаторы хорошо описаны на 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
Отсюда очевидна причина дизайнерского решения: это должна быть красивая симметричная матрица.
В основном это связано с представлением пакета как модуля, управляемого api (отсюда и рекомендация начинать свой пакет с вашего доменного имени - гарантированная глобальная уникальность), поэтому видимость увеличивается с закрытой - > частный пакет -> защищенный -> общедоступный. Если бы protected не был увеличением по сравнению с package-private, а скорее другим типом видимости, должен был быть какой-то способ объединить два типа видимости, когда это необходимо.
В Java 1.0 был пятый модификатор доступа: частный защищенный . Он был защищен без доступа по умолчанию. По-видимому, он никогда не работал должным образом и был сброшен в 1.1. Таким образом, похоже, что утверждения, что защищенный определен так, как он есть для полного упорядочивания, кажутся ложными. ( Редактировать: Похоже, что по крайней мере одна из причин, по которой пятый модификатор доступа был удален в 1.1, заключалась в том, что отсутствие полного упорядочения мешало правилам выбора перегрузки.) Модуль У модификатора доступа в Java 7 есть несколько вопросов дизайна в этой области.
Учитывая, что считалось, что было бы неплохо, чтобы модификатор доступа по умолчанию для членов был "частным пакетом", кажется разумным, что protected должен иметь по крайней мере этот уровень доступа. На мои деньги protected вообще не окупается языком.
Учитывая прогрессивные уровни доступа, частный, пакетный, защищенный и общедоступный, это будет излишне ограничивать, если он будет защищен, а затем пакет, поскольку это заставит меня разрешить доступ подклассам, чтобы предоставить другим членам того же пакета. Тем не менее, интуитивно должно быть так, что другие классы в том же пакете более заслуживают доверия, чем другие классы «там». Таким образом защищен раздел между пакетом и общедоступным, поскольку он обеспечивает более широкий доступ.
Я думаю, что основная причина основана на интуиции, что существует базовый уровень «доверия» между классами в одном пакете; вы можете разумно ожидать, что они будут делать правильные вещи друг с другом - в большинстве случаев за пакет будет нести ответственность один инженер или команда, поэтому должна быть согласованная гармония дизайна.