Именование пакета
Названия пакетов должны избегать конфликтов с другими пакетами, поэтому выбор имени, которое является значимым и уникальным, является важным аспектом дизайна пакетов. Тем не менее, программисты по всему миру разрабатывают пакеты, и нет никакого способа узнать, кто использовал какое название пакета, поэтому выбор единственного названия пакета - проблема. Если мы определим, что пакет используется только в нашей организации, у нас может быть внутренний арбитр, чтобы убедиться, что между проектами нет конфликта имен.
Но для всего мира этот подход не практичен. Все идентификаторы пакетов - это простые имена, и лучший способ убедиться, что имя пакета будет использовать имя доменного домена. Если компания, в которой мы работаем, это Magic.lnc, а доменное имя компании - Magic C.com, то объявление пакета атрибутов должно быть:
пакет com.magic.attr; Обратите внимание, что составные элементы доменного имени здесь расположены в обратном порядке обычного доменного имени.
Если мы примем эту идиому, имена пакетов, которые мы используем, не будут противоречить кому -либо другому, за исключением возможного конфликта в нашей организации. Если в нашей организации действительно существует конфликт (вероятно, крупное предприятие), то мы можем использовать более конкретные доменные имена для дальнейшей квалификации. Многие крупные компании имеют внутренние субдомены, такие как Восток и Европа, которые могут быть использованы для дальнейшего квалификации названия пакета:
Package Corn.magic.japan.attr;
Использование этого решения может сделать имя пакета очень длинным, но оно относительно безопасно. Программисты, использующие эту технику, не выберут одно и то же имя пакета, и программисты, которые не используют эту технику, не выберут имя, которое мы используем.
Доступ к пакетам
При объявлении доступности классов верхнего уровня и интерфейсов верхнего уровня в пакетах есть два варианта: доступ к пакетам (пакет) и публичный доступ (общедоступный). К классам или интерфейсам, измененным с помощью общественности, можно получить доступ к коду вне пакета, в то время как типы, не украшенные общественностью, имеют область пакета: к ним можно получить доступ к другим кодам в том же пакете; Но они скрыты для кодов вне пакета, даже в кодах подпакеков. При объявлении типов мы должны объявлять только те типы, которые другие программисты должны использовать в качестве общественности, и скрывать те типы, которые принадлежат к деталям реализации пакета. Эта технология предоставляет нам большую гибкость, и, поскольку программисты не полагаются на эти типы деталей реализации, к которым они не могут получить доступ, мы можем свободно изменить их, когда хотим изменить детали реализации.
Участники класса, которые не объявляются как общедоступные, защищенные или частные, могут быть доступны непосредственно любым кодом внутри пакета, но скрыты из -за пределов пакета. Другими словами, модификатор доступа по умолчанию - «пакет», за исключением членов интерфейса, а его модификатор доступа по умолчанию является «публичным».
Поля или методы, которые не объявляются частными в пакете, могут быть доступны всем другим кодом в этом пакете, поэтому классы в одном пакете считаются «дружественными» или «доверенными». Это позволяет нам определить структуру приложения, которая объединяет предопределенный код и код заполнителей, где код заполнителя переопределен подклассом класса Framework. Предопределенные коды могут использовать модификаторы доступа к пакетам, чтобы другие совместные коды в пакете могли напрямую доступ к ним, но для пользователей вне пакета эти коды недоступны. Тем не менее, подпакинги пакетов, где расположены эти коды, не доверяют и наоборот. Например, код, измененный с помощью модификатора доступа к пакетам в пакете DIT, не может быть доступен по коду в своем детском пакете dit.dat, и наоборот.
Следовательно, каждый тип определяет три разных контракта:
Метод доступности и покрытия
Только методы, которые доступны в суперклассах, могут быть перезаписаны на подклассах. Если метод в суперклассе не может быть доступен, метод не может быть переопределен в подклассе, даже если метод в подклассе имеет то же имя, что и метод. Когда метод вызывается во время выполнения, система рассматривает его доступность и, таким образом, определяет, какая его реализация работает.
Следующий специально построенный пример объясняется более четко. Предположим, мы объявляем класс абстрактной базы в пакете P1:
Пакет P1; {Ab ab abab public abstract class base private void pri () {print ("stractbase.pri ()"):} void pac () {print ("stractbase.pac ()");} protected void pro () {print ("stractbase.pro ()");} public vide pub () {printbase.) show () pri (); pac (); Pro (); паб(); }}В этом классе мы определяем 4 метода, каждый из которых с различным модификатором доступа, и тело метода только идентифицирует себя. Метод показывает, что эти 4 метода по текущему объекту по очереди. При применении этого метода к различным объектам подкласса он может объяснить, какая реализация этих методов называется.
Теперь мы определяем Class Concetel, который расширяет класс AbstractBase, но находится в пакете P2:
Пакет P2; Импорт p1.abstractbase public class concretel extrables rastractbase {public void pri () {print ("concetel.pri ()");} public void pac () {print ("concetel.pac ()");} public void pro () {print ("concretel.pro ()");} public void pub () {printel.) }4 метода в Superclass переработаны в этом классе, и их реализации изменены, которые сообщают, что они принадлежат к классу Con-Cretel. В то же время их права доступа были изменены на публику для другого кода для доступа. Выполнить следующий код
New Concetel (). Show ():
Будет сгенерирован следующий выход:
AbstractBase.pri () AbstractBase.pac () concetel.pro () concetel.pub ()
Поскольку частный метод PRI не может быть доступен с помощью подклассов (или других классов), метод шоу всегда вызывает реализацию метода PRI в классе AbstractBase. Метод PAC с разрешениями доступа к пакетам в классе AbstractBase не может быть доступен с помощью Concetel, поэтому реализация метода PAC в классе Concetel не может переопределить определение в классе AbstractBase, поэтому метод Show называет метод AbstractBase.pac. Метод PRO и метод паба доступны в классе Concetel и также могут быть перезаписаны, поэтому метод шоу вызывает реализацию этих двух методов в классе Concetel.
Следуйте нашему ноге, знаменитому классу Class Boncrete2, чтобы расширить Class Concetel, а затем мы помещаем ее в тот же пакет P1, что и класс AbstractBase ':
Пакет P1; Импорт p2.concretel public class concrete2 Extends concetel {public void pri () {print ("concret2.pri ()");} public void pac () {print ("concrete2.pac ()");} public void pro () {print ("concrete2Поскольку методы в бетоне имеют права общественного доступа, к ним можно получить доступ в бетоне2, и каждый метод в бетоне 2 охватывает свои соответствующие методы отдельно. Кроме того, поскольку Concrete2 и Abstractbase находятся в том же пакете, метод AbstractBase.PAC также можно получить в Concrete2, а метод Concrete2.pac может быть переопределен. Вызовите метод шоу на объекте Concrete2, и результат печати заключается в следующем:
AbstractBase.pri () Concrete2.pac () Concrete2.pro () Concrete2.pub ()
Наконец, мы определяем Class Concrete3, чтобы расширить Class Concrete2 и поместим его в пакет P3:
Пакет P3 Import P1.concrete2; Public Class Concrete3 Extends Concrete2 {public void pri () {print ("concrete3.pri ()");} public void pac q {print ("concrete3.pac ()");} public void pro () {print ("concrete3 Результат печати выглядит следующим образом: AbstractBase.pri () Concrete3.pac () Concrete3.pro () Concrete3.pub ()Здесь метод Concrete3.PAC выглядит так, как будто он переопределяет недоступный метод AbstractBase.PAC, но на самом деле метод Concrete3.PAC переопределяет метод Concrete2.pac, и метод Concrete2.pac переопределяет метод AbstractBase.PAC, поэтому метод Concrete3.PAC косвенно переопределяет метод AbstractBase.PAC. Изменив метод PAC в Class Concrete2 как наличие разрешений на публичный доступ, к нему можно получить доступ и перезаписан любым подклассом. '