Pakelkonzepl - telematika.kstu.kgVerfügung. Pakete sind organisatorische Einheiten der...
Transcript of Pakelkonzepl - telematika.kstu.kgVerfügung. Pakete sind organisatorische Einheiten der...
15 Pakelkonzepl
Java- Pakete ( jJal-'kap,es) entha lte n inhaltlich zusammen gehörige Klassen und Inte rtaccs. Ein Pak et ist eine logische und (d urch seine File-Stru ktur) auch physische Orgaotsauo nsc tnhcu. Pake te werden durc h das Schlüsselwort package deklariert und
trage n e ine n individuellen Nam en. Durch das Sch lüsselwort import kann au f Pa kc tinhaltc in eigene n Klassen und Interface s zugegriffen we rde n. Dicst.'s Kapitel so llden Pa ketmechanismus (Anlegen und v erwe nden vo n P..kc tcn ) vo rste llen .
Bislang konnten wir unse re Java-P ro jekt e wesentlich durch Codevcrt ctlung auf Klassen lind deren Methoden modularisieren. Vererbung un d Assoz iation erlaubten dieWiederverwendung vo n Klassen innerhalb andere r Klasse n. Alle rd ings ist dieseStrukturteru ngsmöghchkett im Rahmen grögcrcr Systeme noch zu "feinkö rn ig" (g ranubr) - durch das Paketkonzepr ste ht ei n gröberer Stmkturieru ngs-Mechan islllu s zurVerfüg ung. Pakete sind organisato risc he Einheiten der Software-Wiederverwendung
Die JavaSE enthält zahlreiche vorgefertigte Klassen , d ie in d iverse n Paketen zusummengcfussr sind . Bislang ist un s nu r da s Pake t java . l a n g begegne t, zu dessenKlassen z.B. Object, System, String, StringBuffer un d Math ge hö ren. DasPaket java . l a ng wird als quasi unvcrzlcluba r für das Schreiben vo n Java-Klassenlx-trachtet - deshalb wird es automansch import iert. Dagegen ste he n die Klassen aller anderen Pakete e rst durch au sdrücklich e Anweisung zur Verf ügung .
Dieses Kap itel so ll auch we ite re l eiSIl/1/lWIl des Pal.c'elkfmzeJ'ts verdeutlichen:
• Dekla ration öffentlicher Sch nit tstellen bei gczieher Einschränkung der verwe ndung, d.h. Durchserzurig des Gehei mnispri nzips auf hö here r Ebene.
• Deutliche Dokumcnranon von Verwendungen im Code der Verwender.
15.1 Anlegen eigener PakeieKlassen und Inte rfaces könn en eine m Paket ex plizit zugeo rdnet werden. Pakete bilden e inen eige ne n Namensraum und eine Stchrbarkeirsgrenze. Die Inhalte e ines Pake ts sind für andere Pakete nu r sichtbar (ve rfügbar), wenn das Paket d iese Inhalteausdrücklich verö ffentlich t (ex pon iert).
15.1.1 Pakete anlegen mittels package·Oeklaratlon
Wird am Anfang e ine r Qu ellcodedatei ( , j ava -Ftlc) mittels :
p a c kage paketname;
e ine packeqe-Dekla rarion vorgenomme n, so ge hö ren alle Klassen und Inte rfacesdieser Datei logisch zum Paket paketname. Die peckaqe-Dckla mtio n muss als e rste Anweisung im . j ava-Pilc stehen . Wird der gleiche Paket name in rerschiedenen
2 78 15 Pakelkollze/JI
. java-Files verwe nde t, gehören alle Besta mitei le dieser Quellcodefile s zum glei che n Paket.
Die Klassen und Interfaces aller mit dem gleichen Pal'.t'I IIaIl/('11 gekennzeichneter Qu ellcode-Files gehö ren logisc h zum gtetcben Paleet. jedes Paket solltegertau de finierte Zuständigkeiten und Aufgabe n besitzen! Auf diese Weise istd ie Wahrschei nlichkeit hoch, dass die Klassen und Inte rfaces des Pake ts ge me insam wiederverwendet werden könne n.
Pakete ste llen e ine logische Eil/heil da r, deren Klassen und Interfaces über verschiedene .java-Datc icn verte ilt sein kön nen. In Abbildung 15.1 werde n die Klasse nRechnung und Au f tra g in separaten .j ava-Hlcs angelegt. Bcide ge hören jedochzum sclbcn Paket faktura .
.?J package faktura ; d pa c ka ge faktura ;
class Rechnung { c lass Au f t r a g {
; - ... - ; ;- - ;I I
RecbJIIIJll<)m '{l Auft rag.jara
----------- .>:Paket fatuura
uordnungInhalt :akct: IRe Chn ungl IAu ft r ag I
l'hvstschcVel1eilllnt(auf Files:
Lo gische Zzu einem I'
Verzeichnisfa ktura
Ahb. 15.1: Paketdeklarat ion und Klassenzuo rdn ung
Enthält e in . j ava-Fllc keine pa c ka ge-Angahe, so ge hö ren die Klassen und Inter faccs dieser Datei zum nanrenloseu Standardpotset - und werden vom Comp iler imaktuellen Arbcnsvcrze tch rus ge sucht. Somit gehören alle Java-Klassen und -rnrerfaccse ine m Paket an, zumindes t de m Standardpaket.
15.1.2 Pakete alsNamensraum und Sichtbarkeitsgrenze
Jedes Paket bildet einen eigene n tva mensraum: Innerhalb eines Paket s müs sen Klassen- lind Interfacenamen e inde utig sein, in versc hiede ne n Paket en können jedochgleiche Namen o hne Name nsko nflik t verwendet werden. So enthalten betde Paketef ak tu r a und vertrieb in Abbi ldun g 15.2 eine gleichnam ige Klasse Auf trag .
Pakete b ilden auch e ine stcbtbarueusgrenxe. Ohne expliziten Expo rt von Paketinhalten sind diese aulkrhalb des P:.kets nicht sicht- und zugrei lhar.
Die Klassen und Interfaces eil/es palcets haben nur Zugr iff auf Klassen und Inrcrfuccs dl's eige n en Pakets. Klassen lind Inte rfaces anderer Pakete ( Fremd ldasscn und -tnterfacesi haben keinen Zugriff Nur durch expliziten Export
15 ['akell'(JIIZC/J1 2 79
von Pa ke tinhalten kö nne n diese für Fremdklassen und -lntc rfuce s verfügbargemacht werden .
So kann die Klasse Auftrag de s Paket s faktura (Abb. 15.2) auf d ie Sch nittste lleder Klasse Rechnung zugre ifen, da beide dem gleiche n Paket faktura an gehören.Dagegen kann innerhalb des Paket s vertrieb nicht mit der Fremdklasse Auftraggearbeit et we rde n. tb diese ZUlll "fremden" Paket faktura gehört .
~----'-------,
package fa ktura ;
c l ass Re chnung I
/1 OK - gleiches Paket
Auftrag a ;
1/ .. .
r4 package fak t ura ;
c l a ss Au f t r a g
II
IIIII
package vertrieb :
c l a ss Rechnung
1/ Fehler - Fremdpaket
Auftrag a ;
II
c l as s Be stellung
1I
Abb. l S.2: Pakete als Namensraum und Sichtbarkeilsgrenze
Natü rlich werden Klasse n in Paketen zusammengefasst, um diese auch aufserhalhder Paketgrenzen in Ja va-Projekten verwe nde n zu können. Dies erforde rt einen expliziten Export von Paketinhalten durch da s Paket.
15.1 .3 Export von Paketinhalten
Durch ex plizite Kennzeich nung als public werden Paketinhalte ex po rtiert, d .h . einZugriff auch d un:h Klassen lind Interfaces anderer Pakete gewährt:
Pa ketinhalte werden durch ein Paket exportiert, indem Klassen, Methoden,Attribute ode r Interl-aces explizit public deklariert werden. \X'as publicsein soll und für Fremdzugriff von außerhalb des Paketes exponien wird, "hestimmt"somit nur das t'aket seihst.
Die Kennzeich nung pubLic erhalt son nt innerhalb des Paketkonzepts eine z usatzliehe Bedeutung: Auch Klassell und Interfa ce s kön nen ex plizit public deklariertwerden. Nllr auf public de klar ierte Klassen und Interfaces wird der Zugriff aus an deren Paketen gewährt. Unte rbleibt die ex plizite pub l Lc- Dcklaratio n, so ist dieKlasse bzw. das Interface n icht für andere Pakete steht- und verwendbar. Den Ve rsuch, nicht pubLi.c de klarierte Klasse n ode r Interfaces zu nu tze n, quittiert derCompiler mit Feh lermeld unge n.
tunerhalb e ine r pub.Ld c -Klasse kann wiederum dtfferenztert werden , Ire/ehe Allrihute II I/d Methoden für Fremdzugriffe zur Verfügung stehen: Nur explizit publicdeklariert e Attribute und Methoden werden export ten co ösind außerhalb des Pake ts
280 15 ['akelkollze/JI
sich tba r. Der Export von pub.L i c-Auributen und - Mcthoden ist nur wirksam , wenndie zugehörige Klasse se lbst public deklariert ist. Speziell: Bcsuzr e ine publieKlasse nur nieht-p ub l i c Konstruktoren, so kan n sie aus anderen Paketen niebl instanzfiert werden.
Folgendes schematisches Beispiel verde utlicht die Zusanuucnhängc.
package faktura ; 11 Paket faktura , Datei fakturalRechnung .java
publ ic class Rechnung 11 sichtbare Klasse : exportiert
Datum da t ; 11 nicht exportiert
publ i c String name ;
publ ic double be t r a g ;
11 exportiert
11 exportiert
public Rechnung ( Str ing n , double b , int t , i n t m, i n t j )
name = n ; betrag = b ;
dat = new Datum( t , m, j ) ;
public String toString ()
String s - info() + " I n";
11 exportiert
return s + name +
String info ()
" + betrag + " " + da t .toStr i ng () ;
11 nicht exportiert
public int tag ; public int mon a t ;
public Da t um ( int t , in t m, i nt j
tag . t , monat . m, jahr j ;
return " Re c hnu ng Werk 1 I Abt .V I Kostenstel le 08 1 5 " ;
class Datum { 1/ Nicht sichtbare Klasse : nicht exportiert
public int jahr ;
publ ic Str ing toStr ing ()
String s - tag + + monat + + jahr ; re turn s ;
ln jedem anderen Paket (auch dem namenslosen Srnrulardpakct) ist nur die KlasseRechnung sichtbar, die Klasse Datum nicht. Nur auf die explizit public de klarierten Elemente von Rechnung kan n in ande ren Paketen zugegriffen werden. Das Attribut dat und d ie Metho de info () wurden nicht public dek lariert - s ie stehenKlassen {Illdereri':lkele nicht zur Verfügung. Obgleich alle Elemente der Klasse Dat um publ ic sind, kön nen sie nicht au s anderen Paketen angesproche n werden, dadie Klasse Datum selbst nicht explizit pub Li.c deklariert ist.
Die folgende Testklasse ge hö lt de m Paket tests an und zeigl d ie zugntfsmögucbkcitcn auf das p"kel f a kt.u r a : (Auf impo r t wird sogleich cingcgangen.)
15 ['akell'(JIIZC/J1 28 1
package tests ; /1 Paketdeklaration
import f a k t u r a .* : 11 Expliziter Import des Pakets faktura
public c l ass Tester {
public statie void ma i n ( Stringl] a r gs )
11 Erlaubte Zugriffe auf exportierte Klassen und Elemente :
Rechnung r = new Rechnung( "Me i e r " , 1000 . 0, 2 , 6, 2005 ) ;
r .betrag - 2000 .0 ;
IO .writeln( r .toString() ) ;
1/ Fehler: Zugriffe auf nicht exportierte Paketinhalte :
St ring s = r . i n f o ( ) ; /1 Nicht exportierte Methode
[ . d a t .jahr = 2004 ; 11 Nicht exportiertes Attribut
Datum cl = new Datum(1 ,1 ,2000) ; /1 Nicht exportierte Klasse
Bei pubLdc- Pake tklnsscn gilt noch schärfer a ls bei pak et-inte rnen nicht-p ub l LcKlassen: Möglich st keine pub l Lc-Attribute sondern nur pub l i.c-Zugriffsmc thodcn .Nur dadurch bewah rt man die Flexibilnät, die innere Datenrepräsenta tion der Klassein späteren Versionen ohne lnvalidie rung der Verwender noch anpass en zu können.
Eine wichtige vo m Compiler überwa chte Vorsch rift regelt d ie Vert eilung p ub l.Lcde klar ierte... exportieI1<.--'r I'aketklasst.' n lind -lnte rf:Kes au f . j a va -Files:
Eine . j a v a -Quellcodcdatei darf beliebil{ r iefe Klassen un d Interfaces enthal
ten, aber 11111' d llds) davon darf cxpuztt p ub l i c -deidarien sein. Dieser Namebest immt de n tvamen des .j ava-Hlc s. Andere Klass en lind In terfaces de r Datei können von der exportierte n p ub.l Lc -Klassc bzw. dem pubLi c -lnte rfaceverwendet werden. Sie we rden jedoch selbst nicht exportiert.
Somit lllUSS jede public-Klasse lind jedes pub l Lc-lnterface in ei nem eigenen namonsgleichen File impleme ntie rt werden. Für un sere Beispiele sind d ies die FilesRechnung , java lind Tester . java.
15.2 Verwendung von PaketenAuf exportierte Paketinhalte kann in anderen Paketen durch Import zugegriffenwerden. Som it wird im Cod ing deutlich, welche fremden Klassen und Interfaces verwendet werde n.
Voraussetzung für die \/eI7I'eI/(11111& exportierter Klassen lind Interfaces in anderen Pake te n ist de ren ausdrückli cher- Import. 'Vas 1'011 aufsen importiertn-ird, "bestimmt" ///1 1' das renreuelende t'abct seihst.
An m er k ungen: 1. Auch impo rtierte Paketklassen werden in java-Projc ktcn erstda nn gesucht un d zur Laufzeit durch den .IVl\·]-Ciassloadt:r dy nam isch ge laden , wennsie während der t'rogrummausführung benötigt werden. 2. Die Kons tanten eines Inte rfaces sowie die Parameter un d Rückgabewerte sei ne r abstrakten Methodenschnittstellen h innen auch Refe renzen vom Typ andere r Klassen sein. Somit ist es auch
282 15 l'akelkollze/JI
bei m Entwerfen ei nes Interfaces eventuel l e rforderlich, den Inhalt anderer Pakete zuimportieren, um üb er die nöt igen Typinfo rmat ionen zu verfügen - auch we nn dieImplementie rung der Typen dabei nicht in te ressie rt .
Beim Impo rt von Pak te n werde n impliziter und explizite r Import unterschied ..: n.
15.2.1 Impliziter Import
Beim impliziten Import wird jede verwe ndete Paketklasse mit ihrem rollern t'aeet/ IfJ IIICII angesprochen (vollständige Namc nsquahfikation ). Pak e t- und Klassennamewerden durch den t -untuoperator verbunden. Durch vollständ ige Namcnsqualifi kati o n sind auch gleichnamige Klassen rerschiedcner t'alectc ohne Namcnskonflk t verwe nd bar. Som it sind auch gleichna mige eig ene Klassen zulässig. Dies gilt entspreche nd auch für Inter faces.
packaga faktura ;
p ublic c lass Auftrag
packaga faktura ;
p ublic class Rechnung
package vertrieb ;
p ubl ic c lass Auftrag
packaga tests ;
n d r
n d r
n cl
n d
t
t ,.
r
, . ,
Ha .
,.
new faktura .Auftrag ( ) ;
new faktura .Rechnung ( ) ;
new vertrieb .Auftrag ( ) ;
p ublic c lass Tester
publ i c static vo id ma i n(
p mp r
faktura .Auftrag a1
faktura . Rechnung r1
vertrieb . Auftrag a2
String [] a rgs
ug d r h k -Q n
vortcü des impli ziten Import s ist, da ss bei jeder Verwendung im Coding die Herkunft de r ve rwendeten Paketelemente d irekt abgelesen werden kann. Nachtei l istdi e Iänghcbc Schre ibwe ise des qualifiz iert en Name ns. Anders beim explizite n Import .
15.2.2 Expliziter Import
Der explizite Import nutzt da s Sch lüsselwort Impor-t lind ve rsieht die Qucllcodcdate l mit e ine r oder me hrere n aufe inander fo lgenden import-A I/we isungell. Diesemacht den Paket pfad bekannt. Zwei Variante n ex istieren für Klassen lind Interfaces:
• Impor t ei ne r bestimmten Klasse bz w. Inte rfaces durch Name nsne nnung:i mport paketname .klassenOderinterfaceName;
15 Pakell'(J/lze/J1 .!H3
• Impo rt aller Klassel/und Interfaces eines Pakets d urch < Platzhalte r:import paketname . * ;
Für impor t-Anwe isungen gelten einfache Regeln :
• Alle import-Anweisungen m üsse n a11l AnfallR der Qnetlcodedatei ode r d irektI/ach eine r eventuel l vorhandenen package-A l/ u t'islf llgszeile stehen .
• Die import-Anweisungen gelten nurfürdtejeu-etttge Qllellcodedatd, nicht automat isch für alle .j ava-Filcs des Pakets. Somit mü ssen erforde rliche ärnpor-t Anweisungen in jedem reierautcn .j ava -File wiederhoh werden.
• Alle d urch tmpo r t-Anweis ungcn imp ortierte Klassen Lind Interfaces müssenrerscbiedene Namen tragen, so nst tritt e in Samellsl..'OIljlikl au f. In diesem Fallmuss ein impliziten Import mit Paket-Qualifikation ve rwende t we rde n, der Namcn skonfliktc du rch aus drückliche Paketangabe ve rme ide t. tosbeso ndere sindzu explizit importie rten Klassen und Inte rfaces gleichnamige e igene Klassen undInterfaces nicht zulässig.
Mittels explizitem Import kö nnen alle Klassen und Interface s ve rschiede ne r Paketeohne Paket -Qualifikation mir ihrem einfachen Namen verwendet we rde n , sofernkein Name nsko nflikt auftritt. Folgende s Cod ing verwen det wied er das Paket fa ktura des vorigen Beispiels und importiert dessen pubLdc -Klasscn :
n
et
r K
g ,p r
p
$ r.
xp
xp
package tests ;
import faktura .Auftrag ;
import faktura .Rechnung ;
// import faktura . • ;
public c lass Tester {
public sta ti c v o i d ma i n ( St r ing {J a r g s )
ug
Au f t r a g al
Rechnung r l
h -0
new Au f t r a g ( ) ;
new Rechnung ( ) ;
a
An merkung: Die Klassen de s Standardpakets java . l a ng . * sind in allen Qu ellcode dateien auch ohne Import-Anweisungen verfügbar.
15.3 Pakete und VerzeichnisstrukturenBeim Anlegen vo n Paketen muss eine Zuordnung vo n Klassen und Interf aces au fQuellcode- bzir. Bytec odedateien und von l'al..otnamon auf Verzeich n isse des Filcsysrems vorgenommen werden. Drei e infache Regelll legen die Hlesrrukrur fest und gelten für Klassen ebe nso wie für Interfaces:
1. Eine p ub.l Lc- Klassc C muss in einem gleiclma migen File C . java iruplcmcnricrt werden. Dieses wird zum Bytecodefile c . c l ass ko mp iliert.
281 15 ['akelkollz e/JI
2. Ein . j eva-Quellcodcflle darf beliebig viele Klassen enthalten, aber I/ur etne
da von darf public deklariert sein.
3. Alle Files ei l/es Paircis P müssen in dem gleic hnamigen Verzeichnis P liegen.
Für ein Paket namcns f a ktu r a mit de n public-KItL.,:sen Auftrag, Rechnungund Beste llung würde ein Verzeichn is fakrura angelegt werden, das die DateienAuftrag . j ava , Rechnung .java und Bestellung .java enthält (Abb .15.3).Um da s Paket zu verwenden ist der Java-Q uelleode nicht erfo rder lich. Es genügt,da ss das Verzeichnis die zugehöri gen .c l as s -Filcs enthält.
Logtsehe Zuordnungfak tur a Physische
Ordn erstruktur
Jak l tlNI
IAuftrag I IRechnungII Be s t e llung I .......
Auftrag .java oderAuftrag .class
Rechnung . java oderRechnung .class
Bestellung . j ava oderBestellung .class
Abb. 15.3 : Abb ildung t'akctsrrukrur au f Pilestruk tur
Pakethierarchie: Ein Paket kann n-ettere Pa!..!(!/e enthalten, d.h. Pakete lassen sichschachteln. Dad urch könne n gröücrc Mengen vo n Klassen und Interfaces in einerübersich tliche n Paketstru ktur abgelegt werden . Diese wird durch entspreche nde UI/
tcrrcrzcichnissc innerhalb des übergeo rd neten Paketordners abgebildet.
Soll z.B. das Paket betrieb die weiteren Pakete faktura und vertrieb au fnehmen. so muss das Verzeichnis betrieb die Unterverzeich nisse fak tura undvertrieb mit ihren Klassendateien enthalten.
Soll eine Klasse od er ein Inte rface einer geschachtelten Paketstruktur ve rwende twerden, so ist bei m Import der gesamte q ualifizierte Paketpfad (mittels Punk to perator) b is zur Klasse bzw. ZUlll Interface anzugeben. Für genann tes Beispiel lautenmög liche Importanweisungen
// ~xpliziter Import :
i mport betrie b .faktura. Auftrag;
i mport betrieb .faktura . *;
11 nur die Klasse Auftrag
11 gesamtes Paket faktura
// Impliziter Import von Auftrag :
betrieb . fak tura. Auft rag a ~ new betrieb . fak tura. Auft rag ( ) ;
Eine uesonderbeu. Durch den rkuzbatter * we rden nur alle Paketinhalte importiert,die direkt einem Paket zugehören, nicht jedoch die Inhalte der dari n durch Schachtelung enthaltenen Pakete . So würde im Beispiel durch:
i mport betrieb . *;
15 ['a kell'(JIIZC/J1 285
nicht der Inhalt der im Paket betrieb enthalte ne n Pakete faktura und ver tr ieb importiert, sonde rn /lur Klassen und Interf ace s, d ie au f oberste r Ebene desPakets betrieb liegen, Es be ste ht iih rige ns ke ine automarisehe Sichtbarkei t zw ische n inneren lind nuscren Paketen.
Auch die JavaSE enthält Pakethie rarchien . Ein Beispiel ist da s Paket javax .swingmit zahlreichen Unterpaketen wie : j a v a x . swing . tex t . html .parser.
15.3.1 Finden vonKlassenimclass path
Die Standard-Pakete und -Klasscn und - Imcrfaces de r JavaSE (bootstrap dasses)werde n vo m Java-System automatisch ge funde n. Dam it das Java-System jedoch bcnutzerde finierte Pakete, Klasse n lind Interfaces findet , muss deren Ablageort im Darcisystcm be kann t ge gebe n werde n. Dazu dien t das Se/zen dcs classpath (Klasscnpfud). Dies kann durch PIlegen einer gleich namigen Umgebu llgs/'ar iablell gcschchcn ode r durch A llgabe aufder Kommandozeile beim Aufruf dcr Entwicklungstoo ls j a v a und j a v a c . Compiler und .JVM suchen nach Paketen unter dem d urchd ie cjasspath-v anable definierten Dateisystempfade s.
Syntax und \X'd sen der c La s apa t h-Dcflnirion hängen vo m verwendeten Betriebssystem ab. Unter \'\'indows z.B. kann der classpath auf der Konuuandozcilc ge se tzt werden du rch Aufzählung relevante r Verzeichnisse:
set c lasspath: . ;C :\Demos ;C :\Tests ;
Die Pakete m üsste n in diesem Fall im Ordne r C: \ Demos oder C: \Tes ts Liegen .Der Pun kt im c lasspath sorgt dafür , dass auch we iterhin das aktue lle Arbe itsve rzck-hnis durchsucht wird . w e ttere Informat ion en zum c Las spath-Mcchantsmusfinden sich im Zusatzkapitel au f der w ebseh e des Buches. Integrierte Entwick lungsumgcbungcn verfügen über komfortable Mög ltchkcircn de r c La s spa t.h- Pflcgc .
15.3.2 Eindeutigkeit von Paketnamen
I'alectnamen so llten eine n se mantische n Hinweis au f ihren Paketinha lt liefern . müssen jedoch zudem eindeutig sein. Da we ltwe it in j ava entwickelt wird, ist d:IS Finde nweltweit e indeutiger Name n im professionellen Bereich ke ine ganz triviale Aufgabe.
Innerhalb e ine r Organisation kön nen Organ tsano ns-Bcze tchncr in den Paketnamenau fgenommen we rde n . w elrwe tr einde utige l'akctnatucn lassen sich d urch Vo rstel len des lnremet-Domain-Namens erzeuge n [1I0 R02]: Für die deu tsche (DE) DualeHoch schule in Musbach (dhbw-mosbach ) im Studiengan g Wirtschaft sinformat ik ( wi)
erhiel te e in Paket f a kt u r a somit den Paketnamen.
package DE .dhbw-mosbach .w i . faktura ;
Dass d ieser Name vo n anderen Personen oder Institutionen zufällig nochmals ve rgeben wird, ist unwahrscheinlich . Auch d ie Firma SUIl ge ht so vor , wie z.B. im Paketnamcn: com . sun . image . codec . j pe g
286
15.4 Zugriffsrechle im Pakelkontexl
15 ['akelkollz e/JI
Nun sind wir in der Lage , dte genaue Bedeutung der E.IIRr(lJsrechte (Stch rbarke ttcn )pub.l Lc, private lind protected für Attribu te lind Methoden im Paket kontextzu definie ren. Tabelle 15.1 führt die zugrfff srcchre auf. Dabei wird angenommen,dass d ie zugehörige Klasse public ist, d.h. expo rtie rt wird.
publ i c : public int x ; public void m() ( I~ .. . ' 1 }
Zugriff für Klassen un d Ohjdde des eigene n Pakets lind für alle Klassen und Ohjekteimponierender anderer Pakete.
p r o t e c t e d: protected int x ; protected void m() ( 1· ... ·1 }
Zugriff für Klassen und Objekte des eigene n Pakets und für (!lIterklassell importieren der anderer Pakete . jedoch kein zugriff für Objekttostanzen von Unterklussenanderer Pakete. SOlls/ige Klassen un d Objek te der Fremdpakete haben ke inenZugriff.
p a ckag e (= keine Angabe ): int x ; void m(){ 1' . , . '1 f
Standardzugriff Jll II' für Klassen und Objekt e des etsencn Pakets
p r iva t e: private int x ; private void m() { I ' .. . '1
Zugriff nu r in nerhalb der zugehörigen Klasse selbst, nirgends sonst.
ZII f!riffaurctx
Sicbtbarkeit Klasse Unterklasse Paket-Klasse Fre md-Klasse
p ub lic x x x x
protected x x x (x) uo eer-xf.
f!acl~(lge x x xpr i va t e x
Tab. 15. 1: java-Zugriffsrcchtc (Sk'h tbarkcitcn) im Paket kontext
Die Definition von protected ist relat iv kompliziert, da zw ische n dem Zugriff il/
ncrhalb des Klasseneodings und dem Zugriff nter ein tnstanzttenes Objekt unterschieden werde n muss. Im Beispiel e rbt die Klasse GrossAuftrag des Paketstests vo n der Klasse Auftrag des anderen Pakets vertrieb. Inn erhalb des <:0dings der Klasse Auftrag ka nn auf da s geerbte protected Attribut auftragsNrzug egri ffe n werden - nicht jedoch über OfJjekteder Klasse GrossAuftrag:
package vertrieb ; a A a "
publ ic c lass Auftrag protected int auftragsNr ;
package tests ;
import vertrieb ,. ;
c1ass GrossAuftrag extends Auftrag
r . ,
OK: r- d i n m p k
15 ['a kell'(JIIZC/J1
public setauftragsNr( iot nr ) t auftraqsNr
publie c lass Tester {
publ ie statie voi d ma i n ( String[) a r gs )
Gr o ssAu f t r a g 9 = new Gros s Auftrag( ) ;
n r , I
28 7
g .auftragsNr 4711 ; Fehler: K b
Die Eige nschaften von proteered gelten auch für statische protected Anributo undMethode n der Oberklasse . Außerhalb des Codtngs der Unterklasse sind d iese wederübe r deren Objekte noch direk t übe r die Unte rklasse selbst zug re ffbar.
Ein we iteres Be ispiel: Jede Jav a-Klasse erbt von der Klasse java . l a ng . Obj ectderen Methode protected Obj ect clone () . Diese geerbt e Methode kann somit auch in Klassen aufgerufen werden, d ie n icht ZUlll Paket java . l a ng gehö ren ,nich t jedoch auf Obj el..Hell solche r Klassen.
Anmerkung: Anger Zugriffsrechten habe n wir bere its andere Modifiz ierer be i derDek laration vo n Klassen , lntc-rfacc s, Attribute-n , Methode...n und Konstm kro n-n kcnncn gele rnt. Nicht jeder Modifi zicrcr ist auf alles anwendbar. So kön nen z.B. JavaKlassen public de klar iert werde n, niehl aber private ode r protected. lntcrtaccs als Ganzes kö nne n public oder nicht-p ub l Lc sei n, ihr Inhalt ist jedoc h ste tspublic. Tabelle 15.2 nennt den Wirkungshereic h be reits behan delter Modifixicrcr.
Modifizierer Interface Klasse Attribut Met hode Konstruktor
p ubli c x x x x x
protected x x xprivate x x xstatic x xfinal x x xabstract x x x x
Tab, 15,2: Anwendu ngsm öglkhkettcn einiger java-Moctfflzlerer
15.5 Statischer ImportMit der Java 5 wurde das Paketkon zept um den statischen tmpo rt (smtic import ) erwe ttert . Durch das Sch lüsselwort stat ic innerhalb de r Lrnpor t -Anwcisung ste he ngez ielt stat ischen üemente (Methoden, Ko nsta nten, Attr ibute) einer Klasse hzw.Konsta nten ein es Interfaces eines Pakeis zur Verfügung. Der statische Imp011 importiert nur die statischen Eleme nte einer Klasse oder Konstan ten eines Interfaces, umauf diese ohne Na ntensqualtfileation z ueugreifen. Dies ist möglich, ohne von de rKlasse erl-en ode r das Intelface implementieren zu müssen. Allerdings ist ein Ansprechen de s Klas.scn - bzw. Interl-ace-Typs nach nur statische m Import nicht möglich. Die statisch impo rtierte n Elemen te müssen somit oh ne Nennung de s Klassen-
2,';8 15 ['aketkollze/JI
bzw. Interfacenam ens verwe nde t we rde n. Soll der Typ verw ende t werde n, so müsste e ine entsprechende ko nventio nelle tmpor t-Anwc tsuog hinzugefügt werden.
Statische Importanweisungen müssen sich ausdrück lich auf e ine bestimmte Klassebzw. In terface beziehen. Es können e ntwede r alle statis chen Ele mente mittels Platzhalter * ode r bestimmte statische Elemen te einzeln statisch impo nie rt werden. Siesind daraufh in ohne Qualifikation des Typ namens anzu sprechen:
~mport static j a va .lang ,Math . * ; // Alle statischen Elemente
~mport static java . lang.Sys t em . * ; // statisch importiert
~mport static j ava.ut~l , Arrays .sort; // Nur e~n Methodenimport
c l ass Re ch ner
p ublic static void main ( String [ ] a rgs )
double y = sin(PI*2 ,S ) ; // statt : Math .sin( Math .PI ~2 .5 ) ;
sort ( args) ; // statt : Arrays .sort( args ) ;
out. pr~ntln ( y ) ; // statt : System .out .println(y) ;
// Arrays. s o r t ( args // Fehler: Typ nicht verfügbar!
So lassen sich z.B. mathematisc-he Berechnungen elegante r formulieren. Jedoch akzeptiert der Compiler nicht den pauschalen statische n Import aller Klassen e ines Pakcts:
import statie java .lang .~ ; // Fehler: kein Klassenbezug
Es werden somit u.a. Konstantendefinition en in Interfaces ode r anderen Klassen ver fügbar , ohne dass da s Intelface implementiert bzw . von der Klasse geerbt werdenmüsstc , und ohne den Klasse n- bzw. lnrcrtacc nam cn ex plizit anzugeben.
Auch die statisd K' Importanweisung gilt nu r für das .j ava-Hlc, in dem sie e nthalte nist. Sie muss sie in jedem File wiederhol! werden, in de m sie be nötigt wi rd. Wen nstatisch importierte Elemente verschiede ner Klassen namensgleich sind (z.B.: zwe iKlassen Mat h und MyMath enthalte n die namensgle iche Konsta nte P I), moniert derCompiler einen A'ameJlskvJlj7ih Dieser muss da nn doch durch konvention elle n Imporr und voll qualifiziert e Namen (Math . pI) behoben werden. Der statische Importnamensgleicher Jh!thodclI aus Klassen ist jedoch erlaubt, wenn dlcsc sich in ihrerParametersignatur eindeut ig unt erscheiden.
Es empfiehlt sich, de n stattsehen tmpon sparsam einzusetzen. Stattsche r Import istsinnvo ll, wenn oft auf zahlreiche statische Elemente well iger Klassen (z.B. Math )zugegriffen wird. Ein ausufernder Gebrauch mac ht den Programmcode schwererwartbar. da nich t mehr di rekt erkennba r ist, aus welchen Klasse n und Interfaces ulldie verwendeten statische n Elemente stammen.
Einen groben Überblick über die Pakete der verschiede ne n Java-Editionen , sowieden Inhalt de s Standardpakcrs java . l a ng gibt d;IS /.lIsat zl!apilei auf der wcbsc lrcdes Buches. Dort finden sich auch Codebeispiele zu einigen nüt zlich en Klasse n verschiedeuer jav;ISE-l'akete.