[ Pobierz całość w formacie PDF ]

Rozdział 2. f& Klasy i obiekty w Javie 101
2.8. Pakiety
Zaprezentowane dotychczas przykłady klas w Javie były bardzo skromne. W związku
z tym nie pojawiły się jak na razie żadne problemy wynikające z konfliktów nazw
między różnymi klasami. W rzeczywistych dużych projektach niepowtarzalność nazw
jest trudna do zrealizowania. Często może się okazać, że potrzebujemy stworzyć dwie
klasy lub więcej, dla których najbardziej adekwatna nazwa jest już gdzieś użyta.
Gdyby nie mechanizm zarządzania nazwami poszczególnych klas szybko okazałoby
się, że nie możemy już stworzyć żadnej nowej o logicznej nazwie. Jeśli uwzględnić
możliwość importu klas napisanych przez jednego z wielu twórców udostępniających
zasoby w internecie, wkrótce mogłoby również zabraknąć nazw złożonych z zupełnie
przypadkowych znaków. Aby zaradzić temu problemowi, wprowadzony został me-
chanizm pakietów. Umożliwia on stosowanie takich samych nazw klas z zastrzeże-
niem, że należą do różnych pakietów. W praktyce oznacza to na przykład, że możemy
utworzyć trzy klasy o nazwie Grid tworzące i obsługujące siatki elementów różnego
rodzaju. Jedną dla danych tekstowych, jedną dla obrazków i jedną dla przycisków
(siatka przycisków ekranowych to na przykład kalkulator). Pierwsza z klas należałaby
do pakietu texts, druga pictures, a trzecia buttons. Dzięki temu nie tylko możemy
zastosować takie same nazwy, ale nazwa pakietu lepiej identyfikuje naszą klasę.
2.8.1. Tworzenie pakietów
Każdy plik z klasą Javy poza nią samą może zawierać łącznie cztery różne sekcje
tworzące kompletny i w pełni funkcjonalny plik. Sekcje te nie są w żaden sposób wy-
różnione. Podział ten jest tworzony wyłącznie na podstawie zawartości pliku pogru-
powanej według schematu z listingu 2.94.
Listing 2.94. Struktura pliku definiującego klasę
[deklaracja przynależności do pakietu]
[deklaracje użycia innych pakietów]
deklaracja klasy publicznej
[deklaracje klas prywatnych]
Elementy ujęte w nawiasy kwadratowe są opcjonalne. Tak więc klasa nie musi nale-
żeć do żadnego pakietu i nie musi żadnego z nich importować, a przynajmniej tak się
wydaje. Jednak powiedzenie, że klasa nie należy do żadnego pakietu, nie jest praw-
dziwe, bo wszystkie do jakiegoś należą. Jeśli nie jest on jawnie nazwany, wtedy klasa
należy do nienazwanego pakietu domyślnego. Ogólna postać deklaracji przynależno-
ści klasy do pakietu wygląda tak:
package pakiet1[.pakiet2[.pakiet3]];
Wytłuszczony fragment linii to słowo kluczowe informujące kompilator, że następująca
po tym słowie sekwencja jest nazwą pakietu. Pakiety mogą być grupowane w struktu-
ry hierarchiczne z użyciem kolejnych pakietów według podobnej zasady, jak należą
do nich klasy. Tak więc w skrajnym przypadku kilka klas należy do pakietu rzędu
pierwszego. Kilka pakietów rzędu pierwszego należy do drugiego. Strukturę można
102 Java. Programowanie obiektowe
zagłębiać dalej. Kolejne poziomy hierarchii oddzielone są w kodzie zródłowym kropkami.
Struktura nazw pakietów musi odpowiadać strukturze i położeniu plików w podka-
talogach. Tak więc jeśli główny plik aplikacji znajduje się w katalogu c:\java\src,
wtedy pliki z klasami należącymi do pakietu grafika muszą leżeć w katalogu c:\java\
src\grafika, a pliki z pakietu grafika.obrazki muszą znajdować się w katalogu
c:\java\src\grafika\obrazki. W praktyce może okazać się, że pliki z klasami nale-
żącymi do tych pakietów leżą w rzeczywistości w innych katalogach. Katalog zró-
dłowy ustalany jest bowiem na podstawie zmiennej środowiskowej bądz parametru
CLASSPATH. Jeśli więc zmienna ta wskazuje na dwa różne katalogi, na przykład
c:\java\ibm\src i c:\java\sun\src, wtedy klasy pakietu grafika mogą znajdować się
zarówno w katalogu c:\java\ibm\src\grafika, jak i w c:\java\sun\src\grafika. Je-
śli nie wymienimy jawnie nazwy pakietu, do którego należy dana klasa, oznacza to, że
klasy będą szukane wyłącznie w katalogach wskazywanych przez CLASSPATH, a w nie-
których wersjach Javy i jej kompilatorów także w katalogu bieżącym. W praktyce
bardzo często stosuje się kompresję wszystkich tworzonych przez nas klas do jednego
archiwum (typu jar bądz zip) z użyciem hierarchicznej struktury katalogów. Zmienne
CLASSPATH bądz odpowiedni parametr uruchomienia apletu wskazują wtedy na kon-
kretny plik jar, wewnątrz którego znajdują się właściwe klasy we właściwych pod-
katalogach. Aby pokazać zagnieżdżenie pakietów oraz możliwość stosowania w nich
takich samych nazw bez wprowadzania konfliktów, prezentuję na listingu 2.95 zestaw
pakietów dostępnych w Javie 1.1.
Listing 2.95. Lista pakietów dostępnych w Javie 1.1
java.applet
java.awt
java.awt.datatransfer
java.awt.event
java.awt.image
java.beans
java.io
java.lang
java.lang.reflect
java.math
java.net
java.rmi
java.rmi.dgc
java.rmi.registry
java.rmi.server
java.security
java.security.acl
java.security.interfaces
java.sil
java.text
java.util
java.util.zip
Warto zauważyć, że często zdarza się, że na tym samym poziomie zagnieżdżenia wy-
stępują zarówno klasy, jak i kolejne pakiety. Dla przykładu mogą wystąpić pliki nale-
żące do pakietu java.util oraz pakiet do niego należący. Daje to możliwość lepszego
wydzielania i gromadzenia klas w sposób bardziej oczywisty i zgodny z modelem
hermetyzacji obiektowej.
Rozdział 2. f& Klasy i obiekty w Javie 103
2.8.2. Używanie pakietów
Po wprowadzeniu informacji, w jaki sposób tworzyć klasy, aby nie występowały mię-
dzy nimi konflikty nazw i znajdowały się w różnych pakietach, pokażę, w jaki sposób
użyć tych pakietów. Jak to wcześniej pokazałem, plik zawierający klasę Javy posiada [ Pobierz całość w formacie PDF ]

  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • moje-waterloo.xlx.pl

    •