15 Pakelkonzepl

Java- Pakete ( jJal-'kap,es) entha lte n inhaltlich zusammen gehörige Klassen und Inte r­taccs. Ein Pak et ist eine logische und (d urch seine File-Stru ktur) auch physische Or­gaotsauo 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 Klas­sen 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 ra­nubr) - 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 zusum­mengcfussr 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 al­ler 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 n­dung, 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 bil­den e inen eige ne n Namensraum und eine Stchrbarkeirsgrenze. Die Inhalte e ines Pa­ke 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 rs­te 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 gekennzeich­neter 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 verschie­dene .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 Klas­sen- 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 Paketinhal­ten 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 In­rcrfuccs 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 ex­pliziten 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, "he­stimmt"somit nur das t'aket seihst.

Die Kennzeich nung pubLic erhalt son nt innerhalb des Paketkonzepts eine z usatz­liehe 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 r­such, 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 Allri­hute 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 publie­Klasse nur nieht-p ub l i c Konstruktoren, so kan n sie aus anderen Paketen niebl in­stanzfiert 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 klarier­ten Elemente von Rechnung kan n in ande ren Paketen zugegriffen werden. Das Att­ribut 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 Da­t 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ögucb­kcitcn 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.Lc­de 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 Da­tei 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 na­monsgleichen 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 ver­wendet werde n.

Voraussetzung für die \/eI7I'eI/(11111& exportierter Klassen lind Interfaces in an­deren 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 In­te rfaces sowie die Parameter un d Rückgabewerte sei ne r abstrakten Methodenschnitt­stellen 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 ver­we nd bar. Som it sind auch gleichna mige eig ene Klassen zulässig. Dies gilt entspre­che 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 Her­kunft 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 Im­port .

15.2.2 Expliziter Import

Der explizite Import nutzt da s Sch lüsselwort Impor-t lind ve rsieht die Qucllcodcda­te 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 au­tomat 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 Na­mcn 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 k­tura 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 ell­code 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 Filc­sysrems 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 iruplcmcn­ricrt 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 f­nehmen. 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 pera­tor) 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 Schach­telung 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 i­sche 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 bc­nutzerde finierte Pakete, Klasse n lind Interfaces findet , muss deren Ablageort im Da­rcisystcm be kann t ge gebe n werde n. Dazu dien t das Se/zen dcs classpath (Klas­scnpfud). Dies kann durch PIlegen einer gleich namigen Umgebu llgs/'ar iablell gc­schchcn ode r durch A llgabe aufder Kommandozeile beim Aufruf dcr Entwicklungs­too 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 Betriebs­system 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 r­zck-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 lungs­umgcbungcn 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üs­sen 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 rge­ben wird, ist unwahrscheinlich . Auch d ie Firma SUIl ge ht so vor , wie z.B. im Paket­namcn: 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 importie­ren 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 unter­schieden werde n muss. Im Beispiel e rbt die Klasse GrossAuftrag des Paketstests vo n der Klasse Auftrag des anderen Pakets vertrieb. Inn erhalb des <:0­dings 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 so­mit 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 kcn­ncn gele rnt. Nicht jeder Modifi zicrcr ist auf alles anwendbar. So kön nen z.B. Java­Klassen public de klar iert werde n, niehl aber private ode r protected. lntcr­taccs 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 ) er­we 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 impor­tiert 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 An­sprechen de s Klas.scn - bzw. Interl-ace-Typs nach nur statische m Import nicht mög­lich. 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üss­te 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 Platz­halter * 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 ak­zeptiert der Compiler nicht den pauschalen statische n Import aller Klassen e ines Pa­kcts:

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 Im­porr 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 ver­schiedeuer jav;ISE-l'akete.