2009-11-19 2 views
4

В этом посте http://java.sun.com/docs/books/tutorial/java/package/usepkgs.htmlОчевидные Иерархии Пакетов

в пункте «Очевидные Иерархии Пакетов» написано:

«» Во-первых, пакеты, как представляется, иерархические, но они не являются. Например, Java API включает пакет java.awt, пакет java.awt.color, пакет java.awt.font и многие другие, которые начинаются с java.awt. Однако пакет java.awt.color, пакет java.awt.font и другие пакеты java.awt.xxxx не включены в пакет java.awt. «»

, но если я unjar rt.jar я обнаружил, что java.awt.Color и java.awt.font отображаются в иерархическим образом: Java/AWT/цвет и Java/AWT/шрифт так что я понимаю, плохой или в этом сообщении есть ошибка?

Однако возможно ли создать не иерархические пакеты? имена логических пакетов, которые не соответствуют структуре фазовых пакетов?

ответ

6

В статье, которую вы ссылаетесь, объясняется пункт в следующем абзаце. Имена пакетов используются для обозначения отношений с глазами программистов, но не имеют отношения к глазу компилятора. Как объясняется в статье, импорт java.awt.* не будет импортировать какие-либо классы в java.awt.font, они представляют собой совершенно отдельные пакеты, которые не имеют иерархических отношений на языке программирования. Чтобы импортировать все классы в java.awt.font, вам необходимо импортировать java.awt.font.* и не импортировать какие-либо классы в родительский пакет java.awt или в пакеты для сиблинга, такие как java.awt.color.

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

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

7

Статья продолжает

Импорт java.awt. * Импортирует все типов в пакете java.awt, но не импортируют java.awt.Color, java.awt.font , или любые другие пакеты java.awt.xxxx.

Так он просто описывает общее поведение оператора импорта: import package.* импортирует все классы из package, но никаких классов из суба пакетов.

Да, файлы классов находятся в rt.jar только там, где мы их ожидаем, это касается только импорта классов в исходные файлы Java.

Редактировать

Да, учебник добавляет определенную степень замешательства.

Попытайтесь понять пакет как коллекцию классов, которые имеют общее пространство имен. java.awt - это пространство имен, java.lang и java.awt.color - другое. И теперь поймите, что пространства имен java.awt и java.awt.color не связаны. java.awt.color не является «дочерним» пространством имен java.awt. И действительно, в Java нет правила, что вы должны поместить определенные классы в определенные «дочерние» пакеты. Если бы была иерархия, я бы ожидал, что некоторые правила, такие как реализации, должны быть объявлены в «дочернем пространстве имен» интерфейса или около того. Но их нет

Да, фактическое сопоставление пространств имен в файловых системах представляет папку hierachie, где цвет - это папка внутри awt. Это довольно практично, иначе нам понадобится сопоставление между пространством имен пакетов и физическим расположением классов в файловой системе. Теперь мы можем определить местоположение из пространства имен пакета. И это приводит к тому, что эта иерархия верна и для пространств имен пакетов.

Но это не тот случай. И это то, что хочет сказать учебник.

(спасибо за вопрос, я узнал и понял многое, думая об ответе;))

+0

Да, но в параграфе говорится, что "" Сначала пакеты выглядят иерархическими, но они не являются ", но они иерархичны в структуре параллельной файловой системы, поэтому цветовые пакеты включены в пакет java.awt. абзац говорит другую вещь ... – xdevel2000

+0

Ответ был большой для комментария, пожалуйста, посмотрите мое последнее изменение в ответе –

3

Что учебник означает, что не существует понятия суб-пакетов в Java.Пакет может физически находиться в подпапке в файловой системе, но это не означает, что он будет автоматически включен (см. Andreas' answer).

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

1

Именование схемы является иерархическим, а также содержимым файлов jar.

Однако, нет никакой связи между java.awt и java.awt.Color, то есть, например, если вы объявляете класс как пакет частного (без модификаторов) в пакете Foo, он будет доступен от foo, но не от foo.bar.

0

Подумайте об иерархии, как в файловой системе. В Java пакеты похожи на каталоги, а классы похожи на файлы. Пакеты предназначены для размещения набора связанных классов. Когда есть группы пакетов, которые логически связаны друг с другом, их можно назвать так, чтобы они отображались как члены большей иерархии. Глядя на приведенный выше пример java.awt. *, Я мог бы поместить классы для AWT в jar1. Это будет иметь следующую структуру:

jar-1 
    \-java 
     \-awt 

В каталоге AWT вы найдете классы и интерфейсы, которые объявляют себя члены пакета java.awt.

Теперь я хочу, чтобы реализовать некоторые шрифты для AWT, но я положил их в отдельную баночку:

каталог
jar-2 
    \-java 
    \-awt 
     \-fonts 

Шрифт, где классы и интерфейсы для шрифтов, которые я создал для AWT.

Когда вы переходите к программе с использованием AWT и моих шрифтов, сначала вы должны включить как jar-1, так и jar-2 в свой CLASSPATH. Когда вы идете, чтобы включить классы, вы не получите никакой обратной связи, как, к которому баночка компилятор нашел их.

//this loads all classes in the java.awt directory 
// which happen to come from jar-1 
include java.awt.* 

Если вы хотите шрифты,

//Load all classes in the java.awt.fonts directory 
// which happen to come from jar-2 
include java.awt.fonts.* 

К компилятором и runtime иерархия выглядит как одно большое дерево.Это не означает, что все классы физически находятся в одном и том же месте. Сказав, что я должен сделать два очка; 1) Разделение пакетов в одной и той же иерархии на разные банки не рекомендуется, так как это будет запутывать и поддерживать головную боль, а 2) объявлять пакеты как расширения чей-либо структуры пакетов - крайне плохая форма, даже если компилятор позволяет это сделать.