13 Vererbung

Professionelle Softwarccnrwk-kl ung verlangt nach Vorfertigung li nd \fIiede17'UrW('II ­

dung von Konzepten (Wissen ) und Komponenten, um Entwic klungsaufwund nichtmehrfach d urchlaufen zu müssen. Die einfache wtederverwendu ng existiere ndenProgramm cod es pcr Cut&Paste erfordert zwar keinen Entwicklungsaufwa nd. dupl i­zier t aber ide ntische Codestrecken und erschwe rt d ie \X'a rtung des Codes erheblich.Die Objckronc nücrung stellt überzeugendere Konzepte zur Verfügun g - siche rlichauch ein Grun d für deren Sit:gcszug während der letzten zwei jahrzchnre.

Wir haben be re its d ie Asscatation ke nnen gelernt, mit der eine Klasse die Diensteandere r Klassen n utz e n kann : Eine Klasse e nthält Attribute vom Typ anderer Klass enlind gre if! auf deren öffentliche Schnittstelle zu.

Ein noch mächtige res Mittel objektorientierter \X'iederverwendu ng ist Vererhu llg (In­heritance ): Eine Klasse erbt von anderen Klasse n un d kann au f de ren nicht-privateElemente direkt zugreife n, als hätte sie diese selbst implementiert - sowohl inne r­halb ihres eige n Klassencodes als auch über ihre Obj ekte . Zud em e röffne n sich in­nerhalb von Vererbungshiera rchien fasz inierende Möglich keiten generischer, poly.morphcr Programmierun g (Kapitel 14).

Vere rb ung ist e in wichtiges Konzept, um die Komplexität von Software zu vernun­dem , Pnrwlcklungskosren Zll verri nge rn und d ie Entwick lung neuer Anwendun genzu besch leunigen [IIO R02]. Allerdings dient Vererbung nicht nur der bloßen Wieder­verwend ung von Klassencode . Vielmehr erfüllt Objektorie ntie run g auch hier denAnspruc h, die welr in ihren Strukturen modellieren und abb ilden zu können. Oftstüf.~t man dabei au f hierarchische Bep,riJfs/..dllssijiz iel1l1llWIl - Lind gcnau d iese kön­ncn durch verernung darges tellt un d ausgedrückt werde n.

13.1 VererbungshierarchienDie Dinge der realen Welt kommen in viele n Varianten un d Ausprägungen vor, d iesich hierarchisch klassifizie ren lassen. Auf d iese Weise entsteht ein Bcgriffssystcm, indas sich die konkreten Exemplare e ino rd ne n lassen.

13.1.1 Begriffs-und Klassenhierarchien

Aus dem Bereic h der Bio logie s ind Begriffshierarchien wohl vertraut: Das Tierreichlässt sich einteilen in Wirbeltie re lind wirbellose. Bei Wirbeltieren finden sich u.a.Säuget iere und Fische . Bei Säugetieren lassen sich LI.a . Primaten und Huftiere un ter­sc he iden usw. Abe r auch in ga nz and eren Bereichen srose n wir auf Begrfffsluerar­chicn , wie in Abbild ung 15.1 vo rges tellt : Der allgemei ne OhcrbcgriJf Person findetim Kontext einer Firma se ine uontretere Ausprägung im Begr iff des Mitarbeitcrshzw. des Kunden. Bei Mitarbe ite rn kann unte rschieden werden zwischen Pr aktikart­tcn lind Angestellten . Angeste llte kommen in den konkreten Ausprägungen Tarifan-

220 VererbllllR

gest ellter lind Außertarifangestellter vo r. Ein sehr spezieller AlIl~e ltari fa ngestcl l ter islder Geschäftsrührer.

(Sub rypc)

Unterelassen

.'!/1(!zialisienlllp

1

rpcrtypc)

}('rJ...>fassellHasishlasse I Person

erbt 1"00 f01

ß (St

I Kunde I IMitarbeiter Gell(

~ "lsI-Ei

I I[ Prakrtkanr I IAngeste llter l Spezi

~I I

Ta rif- Außerta rif-Angestellter Angest e llte r

Disleri 111 i Ifll taten: ~Tartfstruktur, Arbe trszcnrcg clu ng

Geschäfts-

.Ill1'a-SYIJ/t/X:füluer

class Mitarbeiter extends Person {/ •... • / }

Perso n

Angeste ll te r~----.:.,- Außertar if

Geschäftsführer Angeste llt e r

Ab b . 13.1: Bcgntfslucrarchic als Ve rerb ungs- (U!-H.) und Mengendiagramm

Es entsteht eine baumartig ve rzweigte Begriffs- und Spcztahs tcrun gshtcra rcluc übe rmehrere Ebenen. Den einzelne n IJew4fsklassell lassen sich kon krete Exe mplare zu­o rd nen. Weit oben finde n wir recht allgemeine Oherhegrijji.' (Oherklassell ), die durchdavon abgclc jrctc llllferbeg riJJe ( {Jllferklassell ) immer we iter spezialisiert werden.Hierarchisch tiefer stehend e Begriffskla ssen sind speziellere Ausprägungen übcrge­o rdn ctc r Begriffsklassen . Beim Ga ng "nach unten" unternim mt man eine begrifflicheSpeztattsterung, lx-im Gang "nac h oben" eine Gene ralisierung. Meisl lassen sich we­nige Krite rien ausmachen, d ie die Spez ialisieru ng bestimmen, soge nannte Diskrimi-

Vererhl/I/R 221

nato rcn: In dem Beispiel wären Tarifstruktur und Arbe itszeitregelung solche Diskri ­rninatorcn.

Zugleich entsteht e ine begrifflich e vereröu ngshterarcbie Die speziali siert en Begriffs­klassen besitzen (erben) Eigenschaften und Verhaltensweisen aller übergeord netenBegriffe (Klasse n) er nlang der Vererbungslinie - haben abe r noch weitere Eigen ­schaften lind Verhaltensweisen, die die Oberbegriffe spezial isieren : Jeder Angestel lteist Mitarbe iter lind auch Person , verfügt aber über zuvätzlfch c Eigenschaften undVerhaltensweisen , die ihn z.B. vo n Praktikanten ode r Fre iberufl ern unt erscheiden .

Deutlich wird , wie tnerarcbtsterung. Velt>rlmllg III/d vacdcn-eruendung eina nde rbedi ngen: Eigenschafte n und Verhaltensweisen der Oberbegriffe werden innerhalbder Hierarchie an die Unterbegriffe weitergegeben (vererbt) und in diesen zur Cha­rakrerisierun g wtcdcrverwendet , ergä nzt um weitere spe zielle Kennzeichnunge n.

Ein wichtiger semantischer Test au f sinnvollen Aufbau einer begriffliche Vererbungs..hicrarchic , ist die h.t-e;II ·Rclallol1: Die Vertreter der Unterbegriffe müssen sich alsspe zielle Ausprägungen der Oberbegrüfe ansprechen lassen . Es mus s semantischsinnvo ll se in, zu sage n: Ei/ I (j eder) Unterelassen .. Verlreter ist z ug /eich auch ei n spe..z iel ler Vertreter aller iihergeordl/elell Oberldassen, Im Beispiel (Ahb. 13.1) gilt: JederAußc rtantangcstcllrc ist ein spezie ller Angestellte r. Jeder Angestellte ist ein Miturbci..tc r. Jeder Mitarbeiter ist eine Pe rso n, jeder Außertarifa ngestellte ist eine Person. BeimBegriff des Kunden könnte unsere Modcllk-rung bereits versage n, falls als Kundenauscr natürli chen Pe rso nen au ch Firme n, Institutio nen, Vereine erc. auftreten!

Nur wenn die /st-eil/-Relatio n durchgängig erfüllt ist, macht die Hierarchie scman ..ttsch Sinn, wenn nicht, so resultiert Begr iffsverwirrung. Natürlich gilt die tst-etn­Relation nur in Richtu ng verullgcmctnc rung (vo n unten nach obe n ), nicht umgc..kehrt: Nicht jed e Person ist e in Mitarbeiter, nicht jeder Mitarbeiter ein Angestellter.

Auch durch Mengendtagramme (Abh. 13.1) lassen sich die Verhältnisse übe rsichtlichdarste llen: Die Unterklassen-Elemente sind e ine Teilmenge aller Oberklassen.

13.1.2 Klassen und Vererbung

Diese abstrakten Zusammenhänge werden in der Objektorientierung kon kret aufBez ieh ungen zu-iscbcn Klassen übertragen. Unterklassen kön nen von Oberk lassenderen ö ffentliche Methoden und Attrihute d urch Ve rerbung übernehmen und direktin ihrer Implementierung verwenden. Weitere seihst implemen tierte , spezielle Attri­bute und Methode n kö nnen hinzugefügt werden. Die Unterklassen erbe n von ihrendirekten IlIId tndtreesen Oberklassen entlang der vererbungsluerarclue. Die obersteOberklasse wird Wllrze/klasse oder ttasislelassc genannt. Man spri cht auch von Ablci ..tuug eine r Unterklasse von de r Obe rklasse via Vererbung.

\X'idnig ist die Unterscheidung zwischen Ein fach- und .l!eh lj{u.:hl'ererbll llg Java er­laub t (im Gegensatz zu C++) nu r Einfachvererbung zwischen Klassen:

Eintachvererbung bedeutet , dass jede Unterklasse nur eine direkle Ober­klasse hat. Von jeder Unterklasse führt nur ein einziger \X'eg zu ihren Ober..klasscn. Es entsteht eine Banrnstrnletnr mit e ine r e inzigen Wurzelklasse .Mehrfachvererbung bedeutet, dass ein e Unterklasse mehrere dtreiete Ober-

222 VererbllllR

klnsscn be sitzen kann. Von Unterklassen führen mch rer Wege zu Oberklus­scn . Es liegt keine einfache Baumstruktur mehr vor.

Bei Mehrfachve rerbung kann ein unübersicht liches Vere rbungsgefle cht entstehe n,das zusätzlichen technische n und syntaktische n Aufwand erforde rt .

Jede Unterklasse (subclass) ist eine Speztattsterung ihrer Oberklassen (supcrclass):Beim Aufbau eine r Klassenhierarchie sollten die Obe rklassen allgemeine Methodenund Attribute bereitste llen, die auch in t. nrerklusscn sinnvoll ve rwend bar sind . DieUnterklassen kön nen in ihrer Implementierung die gee rbten Attribut e und Methodenverwende n und durch z usätzliche spezielle Attribute und Methoden ergänzen, dieerst für die Unte rklasse de finiert sind . Vererbu ng sollte nur zur Modcllk - rung vo nSpezialisi erun g verwe nde t we rde n [EILIO].

So verfüge die Oberkla sse Person z.B. übe r das Attribut a l ter. Dies wird an dieKlasse Mitarbei ter vererbt - auch jeder Mirarbeiter hat ein bestimmtes Alter. Erstin de r Klasse Mit arbei ter ex istiert jedoch das Armbur firma - nicht alle Perso­nen sind Mirarbeiter und verfü gen so mit nicht über deren spezielle Eigensc ha ften.Entspreche nd könnten die noch spezielleren Klassen Angestel l ter und Prak ­t i ka n t über spe zifische Methoden zur Gehaltsberechnung verfügen.

Indem man Coding in einer Oberklasse tonzentnen. kö nnen alle erbe nde n Klassendarauf zugreifen , ohne Codestrecken duplizieren zu müssen. Die Oberklasse bleibtbezüglich ihres Coding der alleinige On für Tests, Anpassung , Fehlersuche.

Vererbung ist auch e in weiteres Mittel der Struktueierung- Die be nötigtePnnktionaliriit kann auf verschiedene Ober- und Unterklassen verte ilt werden.Es ist nicht erfo rde rlich, sie in einer einzigen grog cn und unhandlichen Klas­se n zu ko nzentrieren - de nnoch steht sie den Unterklasse n zur Verfügung, alswäre sie dort impk-mcnt iert.

In de r UM/. wird d ie v crc rbungsbc ztchung durch Pf e ile zwischen den Klassensym­bolen dargestel lt, mit Pfeilrichtlilig von der Unterklasse zur d irekten Oberklasse. DerPfe il sagt au s, von welcher Oberklasse eine Unterklasse direkt erbt, verläuft also inRichtung der ISI-ei ll-Heiatio n. Das Diagra mm könnte nur d ie Namen der beteiligtenKlasse n enthalten, oder au ch deren komplette Klassensignatur.

13.2 Vererbung in JavaEine Ja va-Klasse e rbt vo n einer and ere n Java -Klasse , indem sie da s scbtnssetuone x t enda gefolgt vo m Ohcl'klassel/1uiII/(-'1I im Kopf ihrer Klassendeklaration einsetzt.Die Bezeichnung e x t ends lx-schreibt de n Sachverhalt: Die Unterklasse erbt die öf­fentliche Sehnt ustelle und Funktion alir.it ihrer Oberklasse und kan n diese durch zu­sätzlk-hc, untcrklasscnxpc zifischc Attribute und Method en erweitern.

13.2.1 Zugriff auf geerbte Elemente

ln den Beispielen ist das Klasseneoding sehr einfach gehalten , um die Vererbungs­vcrhälmissc deutlich zu machen. Nur um auch die Attributvererbung zu demo nstrie­ren , nehmen wir pubLi.c -Attribute au f.

Vererhl/UR

c lass Person // Oberklasse

223

p rivate String name ;

publie statie int anzahl 0 ;

String getName(} { return name;

void setName( Str ing n} name = n ;

int alter ;

Person( String n ) { name ~ n ;

publie

publie

publie

publie

publie

Person () this( "N .N . "} ;

anzahl++ ; }

c lass Mitarbeiter e xtends Pers o n I 11 Unterklasse

p rivate String f i rma ;

publie Mitarbeiter ( String n , int a , String f }

firma - t :

setName ( n ) ;

a lter = a ;

publie String getInfo ( )

String info getName () + " " + a l ter + " " + anzahl ;

return info + " " + firma ;

pub li e String getFirma ( ) { return firma ; }

c lass Betrieb I

publ ie statie vo id ma i n ( Stringl J args )

Mitarbeiter m '" new Mitarbeiter( " Hub e r " , 25 , " SAP" ) ;

Mi tarbeit e r . a nzah l ~ 100 ;

m. a lter '" 30 ;

ro .wr i ter n r " Da t e n " + m.getIn fo() ) ;

IO . write1n( " Name = + m. ge tNameO ) ;

Die Klasse Mitarbeiter erbt vo n de r Oberklasse Person deren öffe ntliche Ele­mcnrc und emvttet das "Erbe" durch d ie Mit a r be i t.e r-spcziflschcn Methoden qe ­t r n t o () und getFirma () und das Attribut Ei rma . ln de r Unte rklasse Mit.e r ­beiter sind dadurch alle iijJellllic!Jell Elemente - die Metboden getName () undsetName () und das Attribut al ter - de r Oberklasse direkt ao sprcchbar.

Som it kann die Unterklasse Mitarbeiter über diese in ihrer Klassen­Implementierung verfügen. Abe r auch Mi ta rbe i ter-Ohj ekle kön ne n direkt au f ge­erbte Eleme nte zug re ifen, als hätte d ie Klasse Mita rbei te r diese selbst impleme n­tiert. Jedes Mitarbeiter-Objekt verfügt auch über die öffentlich zug reffba ren Me-

221 VererbllllR

rhoden getName () und setName () und das Attribut al ter, neben Hemenren.die in Mitarbeiter selbst zusiitzlich imp lementiert sind .

Die ciffelltlichell Elemente (Attribute lind Methoden) de r Oberklasse steheninner halb des Codings der erbe nden Unterklassen und au ch für deren Objek­te zum direkten 7.lIgr(ffzur Verfüg ung. Dabe i kan n es sich tun nicht-stat ischeebe nso wie statisc he Elenu-rne ha ndeln.

Vererbung funk tion iert nur in eine r Richtung: Die Unterklasse verfügt über eige neund gee rbte Methoden und Attribute, während für Obe rklassen d ie Methoden undAttribute ihrer Untc-rklaxscn nicht s ichtbar s ind .

Ober- und Unterklasse n können im gleichen . j a va -File implementiert se in, oderauch in versch iedene n Quellcodefiles. Lm vo n einer Java-Klasse abzuleiten ist derenQuel leod e nicht erforde rlich, der Bytecode t . class-File ) ge nügt.

Anmerku ng: Eine z.I'Uische, wechselseitige Vere rb ung zwische n zwe i ode r mehrKlassen wird vo m Compiler zur ückgcwiscscn. Das Codmg.

c lass A e xt.ends B { / ~ ...~/ I c Las s B e x t e nd s A { /~ ...~ /

produziert die Fehlermeldu ng cyclic inheri tance, ebe nso wie:

class A extends C {} class B extends All class C extends B {}

13.2.2 Kein Unterlaufen derKapselung

ln Unrcrklassc n sind alle öffentlichen Method en und Attribute aller ihrer Obe rklussenve rfü gbar. Jedoc h haben die erbe nde Unte rklasse und ihre Objekte ebe nso wie jedeandere Klasse tseinen 7./Igriffü/lf die ortraten Elemente der Oberklassen. Diese blei­ben das lmplcmenrteru ngsgeh cimnts der Obe rklasse und sind unter ihrer ötfent li­eb en Sd 1l1itlsle lle ve rborgen . Private Eleme nle der Oberklasse werden nicht vererbt.

Nur die öffentlichen Elemente eine r Klasse werden ve rerb t , nicht ihre pri­vatcn Elemente. Die Schnittstelle und Kapselurig e ine r Oberklasse kan n au chd urch Vererbung nicbtuntortaufen werden.

Der Compiler verhinde rt den Zugriff auf private Oberkla sse nelemente. Somit ist fol­ge nde Mit e rbe i. t e r -Mcthodc getlnfo () fe hlerhaft.

class Mitarbeiter extends Person {

/ / . . , Fehler : name privat in Oberklasse Person !

public String getInfo ( ) t

return name + " " + alter + " " + f irma ;

Der Compiler meldet: n a me has p r ivate a cces s i n Person,

Durch Unterklassen ist jedoch durchau s ein tndtreeter Zugriff auf private Eleme nteder Oberklasse möglich se in - über entsprechende öffe ntliche Methoden de r Olx-r­klasse. In unserem Beispiel kan n die Unterklasse Mirarbeiter übe r die geerbten öf-

Vererhl/IIR 225

fenrltchen Methoden getName () und s e t Name () den Wert des privaten Attributsname der Oberklasse abfragen und ve rände rn.

Mit de n Unterklassenobjekten werden deshalb auc-h zugehörige Oberklassenobjek teund ihren Daten im Speicher ge halten. Diese werde n automatisch mit den Unter­klasscnobjcktcn erzeugt. Auch dazu finden Konstruk roraufrufc statt. Die Objcktcr­zt:ug ung in Klassenhierarchien muss somit noch gesonde rt unte rsucht werden.

Neben den Zugri ffspezifikationen public (w ird vererbt) und private (wird nichtvererbt ) existiert in Java auch die Zugriffsspezifikat ion protected . Diese regeltVererbung innerhalb des java-Pukctk onzcpts, auf das wir in Kap itel 15 einge he n .Auf p r Lva t e- Elcmenre hat nur die Klasse selbst d irekt en Zugr iff, auf public­Elemen te die Klasse, ihre Unterklasse (via Vererbung ) lind au ch alle anderen Klas­se n (via Objcktcrzcugung).

13.2.3 Aufruf des Oberklassenkonstruktors

Aus dem Uutcrklasscn-Ko nstruktor he raus tsaun ein vorhandener Oberklassen­Konst ruktor mit passenden Parametern aufgerufen werden. Dazu dient der Mctho ­

denaufruf super (), dem im angc pasten Beisp iel ein String mitgegeben wird:

class Mitarbeiter e xtends Person I 11 Nutzung super()

private String firma ;

public Mita r beiter ( String n , int a , Str ing f ) (

super( n ) ; 11 Aufruf Oberklassenkonstruktor von Person

I

//

firma'" f ; alter'" a ;

Konstruktoren werden nicht vererbt. Die Unterklassen müssen im Beda rfs­fall eigene Konstruktorcn imp lementieren, kö nnen aber aus d iesen mittelss upe r 0 -Aufrnf einen Konstrukror der direkten Obe rklasse aufrufen.

w enn verwendet. muss der super () -Aufruf die erste Anweisung im Unterklassen­konstrukro r sein - folglich kann er nicht mehrfach im seihe n Konst ruktor erfolgen.

Durch super () wird der passende Konstruk tor de r direkten Oberklasse aufgerufen- vielle icht ve rfügt diese ja ühcr mehrere überladene Konstrukrorcn. Die Parameterwerden übergebe n und der Obcrklasscn-Konstruk tor abgearbeitet. Danach keim derAufruf zurück und d ie Abarbeitung des Untcrklasscn-Kon strukto rs wird fo rtgese tzt.Auf diese \,\'e ise kön nen z.B. private, nicht d irekt zugängliche Attribut e de r Ober ­klasse (hier: Attribut neme ) durch Unte rklasse n mit Initialwelt en bei der Objekter­zeugung ve rsehen werden.

Folgendes schematisches Beispiel zeigt ein e Folge aufsre igender super () -Aufrufc .Stets wird der mit super () aufgerufene Konstrukror komplett abgearbeitet , ehe de rKontrollfluss hinter dem jeweiligen super () -Aufruf fortserzt.

cJ.ass Oben I

2.lG 13

public Oben( int n ) 1 IO .write( " Obe n mit " + n +

class Mitte extends Oben

Vererb llllR

" ) ; I

p ublic Mitte ( i n t m )

super ( 2'*m 1 ; IO .write( "Mi t t e mi t " + m + " " );

class Unten extends Mitte {

public Unten( i n t k )

super( 2'* k l ; I O. wr i t e ( " Unt e n mit " + k ) ;

public s t a t i c void main( String[] args) I

Unten u 1 = new Unten ( 10 ) ;

- Konsole ­Oben mit 40 Mitte mit 20 Unten mit 10

Anmerku ng: Der super () -Aufruf erinnert an den this () -Aufruf Durch su ­per () wird e in passend parametr isicrrer Kon srruktor der direkten Oberklasse aufge­rufen, durch this () ein passe nd paramctris icrrc r Konstruktor der eigene n Klasse.Da sowohl this () als auch super () e rste Anwe isung im Konstruktor sind , kö n­nen nicht bekte Anwe isungen im selben Konstruktor au ftreten.

13.2.4 Vorgänge bei Instanziierung von Unterklassenobjekten

Der super ( ) -Aufruf zeigt an, da ss bei Erzeugung e ines Unterklassenobje kts auchOberklasseobjekte im Sp..;id ll' r angelegt werden:

\'('ird e in Unterklassenobjekt e rzeugt, so wird d urch die )V!\I auch atucnna­fisch fü r alle Om:I'k!{/SS('1I e in O/Hckf im Spek-hcr angelegt.

In diesen Oberklassenobjekten werden die 'x'ert c vererbte r öffentlicher Attribute ge­spe ichert, die für die Unterklasse und ihre Objekte direkt zugreifbar sind . Durch ge­e rbte ö ffe ntliche Methoden und super () -Aufrufc können ind irekt auch private An­rlburc der Oberklasse angesprochen werden, Auch deren w ert e werden in dem au­tomat isch erzeugten Oberklassenobjek t ab gelegt.

Abbild ung 13.2 skizziert die Vorgänge. Die Erzeugung e ines Mitarbeiter-Objektsführt auch zum Anlegen eines Pe r s onen-Objckts.

Auf d ie automatisch an gelegten Objekte hat man keinen direk len Zugriff, jedochwe rden sie über die Unterklasse und ihre Objekte indirek t angesprochen. DurchKonstrukterausgaben kan n man sich von der automattseben OIHel!/erzeu[!, lIJ1g in ei­ner Klassenhierarchie überzeugen.

Vererhl/ IIR 22 7

ItAM

Klasse Person

Klasse Mitarbe-iter

Objek terzeugung Untcrklasscnobjckt:

Mitarbeiter m ~ new Mitarbeiter( ... ) ;

Klasse Person

Klasse Mirarbe iter

1'l'rsOJIl'JI -übjekt

RAM

Abb. 13. 2: Automatische Erzeug ung vo n Oberklassco ohjckrcn

class Oben I

public Oben ( t r.o .wr t t.e r " Obe n i " ) ; )

class Mi t t e e xtends Oben I

public Mitte( ) ( lO .write( " Mit t e ! " ) ; I

class Unten e xtends Mitte I

public Unten ( {lO .w rite( " Unt e n ! " ) ; I

public static void main( String!] args)

Unten ul = new Unten( ) ;

l Ob e n !- Konsole -

Mitte! Unten!

Ohne dass ein super () -Aufruf erfolgt, werde n IX' i Erzeugung des Untcrklasscnoh­jckrs ul die pa rameterlose n Oberkbssen-Ko nstmktoren a l/tomarisch au fgemfen.

w enn in den Unterklassen-Konstrukteren tsetne expliziten s upe r () -Antrufeentha lten sind. da nn setzt doch der Comp iler einen parameteriesen supe r ( )­Aufruf e in, so dass Oberklassenobjekte au to m at isch erzeugt werden.

Die Rdhenfi JIIW de r Objek te rzeugung entspricht de m Pfad durch d ie v crcrbuogshrc­rarchic vo n de r Basisklasse bis zur ko nk reten Unterklasse . Zuerst werden die Ober­klasscnobjckrc erzeugt, erst zuletzt wird das Unterklasse no bjekt ange legt.

Zu beachten ist: Excc prions, d ie :HIS de r Abarbcitung des Obcrklassen-Konsrruktorsresultieren, kön nen im Untcrklasscn -Konstruk to r nicht abgefange n werden. Wenn

228 VererbllllR

die Erstellung der Oberklassen-Objekte scheite rt, so ist d ieser schwerwiegendeSch iefsta nd im ü nrcrkla sscn- Konsrruktor nicht mehr zu bereinigen.

13.2.5 Konstruktoren in Klassenhierarchien

Enthalten die ü nrcrklussen-x onsrruktorcn keinen super () -Aufruf wird ein paramc­torloser super () -Aufruf durch den Compiler automatisch ge ne riert. Dieser Aufrufstellt kein Problem dar, wenn d ie Oberklasse entwede r u.a. e inen parameterlesenKonstrukror ode r aber gar keinen Konstruktor tmplcmcnucrt. Denn im zweit en Fallsteht dann der parameterlose Srandardkonsr ruktor zur Verfügung. so da ss der su ­per () -Aufruf gel ingt.

rrcöknnauscb ist jedoch eine Oberklasse . die nnrpammetrisiortc KOJlstruNOI'l'11 im­plcmenrtert. Diese besitzt kein en parameterlosen (Sran da rd-) Konsrruktor, so da ssder vom Compiler generierte super () -Aufruf fehlsch lägt.

class Oben I // Hat keinen parameterlose Konstruktor

public Oben ( int n ) t IO .writeln( "Ob e n : " + n ) ;

class Unten e xtends Oben

public Unten ( ) ( // Fehler!!

// Compiler setzt ein : super ( ) ~ schlägt fehl!

IO .writeln( "Un t e n " ) ;

public static void main( String[1 args) I

Unten u = new Unten( ) ;

Der Compiler sucht vergeblich eine n parameterlosen Konstruk to r in Oben und 1II0 ­

niert: cannot resolve symbol symbol : constructor Oben ()

Abhilfe schafft . der Oberklasse eine n (eventuell fun knousloscn ) parameterlosen öf­fentlichen Konstruktor hinzuzufügen: public Oben () { / * ... * / }

ln Tabe lle 13.1 sind die mög lich en Eille zusammengefasst.

\\ 'i11 man Vererb ung einsetzen, so IllUSS man sich mit dem s upe r () ­Mechanismus auseinandersetzen.

13.3 Überschreiben (Overriding)

Die geerbten Attribute und Methoden aller Oberklassen stehe n der Unterklasse dt ­rckt zur Verfügung. Allerdings ist de nkbar, U:1SS eine Unterklasse nicht das kompletteMethoden- oder Attribut-Erbe "antreten" möchte: Eventuell soll sie spe ztattstene .1[e­thoden implementieren mit gleichem Namen und Signatur ab er anderer huplernen­tierurig als geerbte Oberklassenmethoden . Oder namensgleich e Attribute anderen[)al(,I I (~1'S als geerbte Oberklassenattribute so llen angelegt werden.

Vererhl/ I/R 229

Beispielsweise k önn te von der Klasse Mitarbeiter die Klasse Anges te llterabgele ite t werden. die übe r e ine anders implementierte Methode ge t ln fo ( ) verfü­ge n, ode r ein Attribut a l ter vom Typ double statt i n t be sitzen soll.

Oberklasse 0 Unterklasse U r'olec

Hat nur paramctrtsrcrrc a ) Ruft parametrisiertcn O-Konstmktor auf: OK!Konsrrukrorcn U (){ super( n l , c l , . I ; I

b) Ruh beineu O-Konstnl ktor auf: Febler!

Compiler generiert. super() ;

Hat a l/ch parameterlosen a ) Ruft para metertosen O- Konstrukto r auf: OK!xonsrrukror U (){ super ( ) ; I

b ) Ruh keil/eil O-Konstruktor auf: OK!

Com oik-r rcncricrt: super () ;

Hat A!Cil ICI/ Ko nstruktor => Ruft te tnen OiKonstruk to r au f: OK!parameterloser Stnndarko n- Compiler generiert: super () ;struktor zur Vfg.

Tab, 13.1 : Konstrukteren in Klassenhierarchien - mögliche Pälle

Natürlich kö nnte die Unterklasse Angestellter dazu einfach neue Methoden­und Attributnamen e infüh re n, wie get ln foAngestel 1ter () ode r a l te rAnge­s tell t e r _ Jedoch würden auf d kse Weise für semantisch aqutrate.ue Dinge neueNamen eingefühlt : In der Unterklasse Anges te llter gäbe es ein Nebe neinande rgeerbter und angepasster Methoden und Attribute . Entlang eine r v crcrbungslucrar­chie würden sich immer mehr durch Vererbung weitergegeben e Methoden- I/ I/ d A ff ­

ributranantcn al/häufen und die Schnittstellen der Unterklassen b is zur Unübe r­sichtlichke it aufblähen - was de m Grun dsa tz schlanker Schnitt stellen widersprich t.Neue Name n für Methoden und Attribute sollten in Unte rklassen nur für semantischneue Elemente verwendet werden. Der Mechani smus des Übersch reibens tovem­d ing, cngt.: sich hinwegsetzen ) von Metho den- und Attributnamen löst das Problemelegant ohne zusätzliche Namen einzuführen und d ie Verwender zu verwi rren.

13.3.1 Überschreiben von Methoden

Das Überscbreiben ron s tett oäemtamen ( rnethod name orerriding) erlaubt, geerbteMethoden in de n Unterklasse n zu spez ialisieren und unter gleichem Namen flexibelan un terklassenspezifische Bedürfn isse anz Llpassen , um z.B. ande re interne Daten­formate zu verwe nde n, zusätzliche Rest riktionen , Invar ianten und Prüfu ngen durch­zusetzen ode r die entsp reche nde Funktion alit ür zu verändern.

Dito' Klassenhierarchie Person +- Mit a rbe i ter wird durch die Unte rklasse Ange ­s tell t e r crweirc t. Diese überschreibt die geerbte Methode get lnfo ( l , um ihrzusätzliches Attribut gehal t c tnzub ringc n

23 0 VererbllllR

class Ange stell t e r e xtends Mi t arbeite r I

private double gehalt ;

public Angestellter( String n , int a , String f , double 9 ) {

super ( n , a , f ) ;

gehalt'" g ;

publ i c String g e tlnf o ()

String info getName() + " " + al ter + " " + anzahl ;

return info + " " + getFirma() + " " + gehalt ;

Die Klasse Angestellter erbt vo n Person und Mitarbeiter. Obgleich s ie dieMitarbei t e r-Mcthode getlnfo () erbt , implementie rt sie eine eigene , a ngep:t~s­

te Varian te. Beim Aufruf innerhalb der Klasse Angestellter und auf Ange ­s t e Ll t e r -Ohjcktcn wird diese Angestellter-spe zifische Methode aufgcrufe n >­

nicht die geerbte getInfo ( ) -Mcrhodc : lUS Mit a rbe i. ter . Die gerbte Methodegetlnfo () wird durch Übe rschreiben re rdeckt:

class Betrieb {

p ubLi.c statie void main( String[] a rgs ) {

Angestellter a = new Anges tell ter( "Huber " ,25 , "SAP " , 3000) ;

IO .writeln( "Ange s t e ll t e r : " + a . get l n f o() ) ;

Mitarbeiter m - new Mitarbeiter( "Meier" ,30 , "IBM ") ;

IO .writeln( "Mi t a r b e i t e r : " + m.getlnfo () ) ;

- KonsoleAngestellter :Mitarbeiter :

Huber 25 1 SAP 3000 .0Meier 30 2 IBM

Für Mitarbeiter-Objekte wird we iterhin die Ni t a rbe i t.e r -Mcthodc ge tln ­fo () aufgemfen.

überschreiben einer Methode bedeutet Deklaratio n ein er Unterklassen­Methode mit gleicher stgnatur tMcthodcnkopf Name , Paramete r, Rückgabe­wert e ) wie in der Obcrklassc, jedoch anderer Im!Jlemell/ienmg (Methoden­k örpcr).

Der Rückgabetyp darf sich heim Übersch reiben nich t ände rn . Nicht-stat ische geerbteMetho den kön nen nur nicht-stat isch übe rsch riebe n werden , startsehe geerbte Me­rhoden nur durch statisch e Methoden. Eine weitere wichtige Regel, d ie der Compilerüberwacht, l:llllet:

Beim Überschreiben von Methoden in Lnrcrklasscn dürfen ursprü ngliche7.lIgriJ)slt'chte nicht eil/geschränkt werde n. Die Unterklasse darf hier hinsie-ht-

Vererhl/ IIR 23 1

lieh der Zugriffsrech te nicht strenger sein als ihre Oberklassen . Sinn der Regelist, dass heim Überschreiben die Schnittste lle (de r Vert rag ) de r Oberk lasseauch in de r ange passte n Unrcrklassen-Jmplc mco nc nmg e ingeh alten wird.

Eine publ Lo-Mcthodc der Oberklasse darf in de r Unterklasse nicht durch cmcprivate- oder p rotected-v ar iantc überschrieben we rde n . Deklarierte man inAngestellte r die Methode p r ivate getlnfo () {} , so meldet de r Compiler: cen­not reduce the visibility of the inherited methad fram Mitarbeiter ,

Anmerkung: Man verwechsle nicht das ttnerscbretben (ovcrriding) und Ühertaden(ovcrloading ) vo n Methodennamen . Übe rschreiben bewirkt Verdecken geerbte r Mc­rhoden in Unte rklassen. Überladen erlaub t mehrere gleichnamige Methoden unter­sch iedlicher Parameterleisten inne rhalb eine r Klasse .

Das irrt ümlic-he "Überschreiben" einer gee rbte n Oberklassenmethode durch eine Ln­tc rklasscrunc thodc anderer Paramct rlslcrun g bede utet in \X1irklichkeit ein Überladende r gee rb ten Methode in der Unterklasse . Somit würde die folge nde modifi zierteKlasse Angestellter zwe i Methoden get lnfo () besitzen - die von Mitarbeitergeerb te Fassung und ihre überladene Version:

elass Ange s t e l l t e r e xtends Mitarbeiter

/ / , ..publ ie Stri ng getlnfo( double 9 l I / ' ". '/ I

Um ein unbeabsichtigtes Überladen zu ve rhindern kan n ab .JavaS d ie Annotation@Qverride verwende t werde n. Dad urch prüft der Comp iler, ob d ie gee rbte Mc­thodc wirklich übersch rieben oder (unab sichtlich) übe rladen wird:

elass Ange s t e llte r e x t e nd s Mita r bei t e r I

/ / ".

p ubl i e String getlnfo (

@Ove r r i de // Hier : Compilerfehler !

d oubl e 9 l I j" . . . -/ I

Annotattonen d ienen als Quellcode-Marker, d ie durch ve rschiede nste Tools (nichtunbed ingt Com pile r) ausgeweitet werden können. Semantik und Ausfüh rung desProg ramms werden dad urch nich t direkt beeinflusst. Neben vorde finierten Anno tati­one n w ie @Qverride kön nen Anno tat ione n auch sd bst dc fimcrt we rde n. WeitereInformatione n dazu finde n sich au f unserer Websehe.

Super-Aufrufe geerb ter- verd eckter Methodem

Auch nach Übe rschreibe n geerbter Methoden in der Unterklasse können diese ve r­deckten Methoden we iterhin im Coding der Unterklasse aufgerufen werde n. Über­schriebe n Methoden lassen sich mittels supee-Refcrenz au f die vere rbe nde Ober­klasse exp lizit aufrufen. Die Syntax des super-Aufrufs lalltet :

super . me t hod e nna me ( parameter, . . . ) ;

232 Vererb llllR

Dies garun uert Plexlbihrär. In unserem Be ispiel du plizielt die Met hode get Info ( )von Angestel l ter einen Grossteil de s Codtngs der überschriebe nen Mitarbei ­t.e r-Mct hodc. Ein super-Aufruf der Oberklassenmethode ist viel eleganter :

class Ange s t e l l t er e xtends Mita rbeiter I

private double gehalt ;

public Angestellter( String n , int a , String f , double 9

s uper ( n , a , f ); // Oberklassen-Konstruktoraufruf

gehalt = g ;

p ublic String getlnfo( )

// Aufruf geerbter Methode durch Oberklassenreferenz :

return super .getlnfo ( ) + .. " + gehalt ;

Durch den super-Aufruf wird die geerbte Methode getlnfo () aufgerufen undinnerhalb der überschriebenen Variante wiederverwendet. Trotz ü be rsch reiben src­hcn geerbte Methoden in der Unterklasse weilerhin "o riginal" zur Verfügung.

Das Überschreiben ge erbter Mcthod ...-n die nt auch zur Einführu ng zusätz licher se­mantischer oder tech nischer Konsiste nzprüfungen in de r Unterklasse. Vererbung IX'­deutet nicht nur bloße Wiederverwendung sondern auch Spezialisierung und Anpas­sung. So ist in folgendem Be ispiel ein Übe rbuch en eines Fluges ist mit Unterklus­senobjcktcn nicht mehr mögl ich, o bwohl die geerbte allzu o ptimistische Oberklas­senmethode mittels super-Referenz wiederverwen det wird:

class Flug {

private int buchungen ;

public void buche ( ) buchungen++ ; I

public int getBuchungen( ), return buchungen ;

c lass GepruefterFlug e xtends Flug

private int ka p a z i t a e t ;

public GepruefterFlug( int kap) { kapazitaet "" kap ; I

p ubl i c v o id buche ( ) // erst Voraussetzungen testen :

if ( getBuchungen() + 1 <= kapazitaet ) super. buche () ;

Dies ist zugleich ein Beispiel für defensives Prog rammieren. Start mit optimistischer"try -and-sccv-Haltung sollte ei nt.' Klasse nach dem konservativen "chcck-and-act"­Prinzip [I.EAOOI entworfe n werden. Statt nachträglich fehle rhafte Zustände und In­konstsrenzcn zu beheben, sollte man entspreche nde Aktionen nur durchfü hren,

Vererhl/IIR

wenn deren Voraussetzungen (prccondtt lons) e rf üllt sind , um System-Schiefstä ndelind deren mühsame Korrektur vo n Vornherein zu vermeiden .

Einschrän ku ngen: Ein supe-r-Aufruf ist nur im Coding einer Unte rklasse mögl ich ,nicht auf eine m ihrer Objekte . super () -Aufrufc lassen s ich nicht re rieetten, d.h . e inBezug auf Eleme nte höherer Oberklassen wie super , super . me t h od e () ist nichtmöglich. Ferner steht in statischen Methoden die super-Refe renz nicht zur v erfü­gung. Auf übe rsch riebene statische Met hoden (und Attribute} kann in Unterklassennur aus nicht-statischen Methoden zugegriffen werden. Andernfa lls meldet der Com­pilc r: Cannot use super in a static context !

Es bezieht sich super imme r auf die implement ierende O berk lasse. Die Klasse An­gestellter kö nnte auch die geerbte Pe r son-Mctho dc getName () üb erschrei­ben und mit super . getName () die urcprünglk-hc Variante von Person aufrufen ,obgleich Person nicht di rekte Oberklasse von Angestellter ist.

Anmer kung: Man verwechsele nicht den Oberklasscn-Konst rukror-Aufruf durch d ieM e/hode super () mit der super-Oherklassen-N(1el'ell z. Durch die super-Rcferenzreferenz lert man e xplizit die Oberklasse. so wie sich eine Klasse durc h die this­Referenz exp liz it auf sich se lbsl bez iehen kann.

Metbodenauswah l d urch dieJVM:

Bei m Übersehretben von Metboden mu ss die ,1V,\1 zur Laufzeit die jeweils richtigeau szufüh rende Methode in de r Vererbungshierarchie finden ca yna mtc inrocation).Dabei werden für ein Objekt eventuel l Metho den aus verschiedenen Ebenen derHierarchie ausgeführt:

Angestellter a '" new Angestellter ( " Hub e r " , 2 5 , " SAP", 3000 ) ;

IO .writeln( "He r r " + a.getNameO + ". " + a .getlnfo O ) ;

Für das Angestell t e r -Objckt a wird d ie überschriebene Methode get Info ( )au s Angestel l te r aufgerufen, wä hrend getName () aus Pe rson stam mt.

Das SlIch/Jrillz/j) der.lEH : Bei jedem Methodenaufruf wird geprüft. ob die Methodein d ..: r Klasse des aufrufenden Objekts vorband en iSI. Wenn ja, dann wird die dortimp leme ntierte Methode ausgefüh rt. Wl'n n nicht , dann wird die Suche im Codingder O berklassen fortgesetzt. bis d ie gerufene Methode gefunden ist. Spätestens inder Bastsklasse iSI d ie Methode zu finden - sonst läge e in Compiler-Feh ler vor.

13.3.2 Überschreiben von Attributen

Die gleichen Mechanismen greifen beim OberschreiheIl geerb/er Attribute in den Un­tc rklasscn . Die Deklaration e ines gleichn amigen Attributs beiiehigen anderen Daten­1)1)S in der Unterk lasse verdec kt das geerbte Attribut. Das verdeckende Attribut darfbeliebige Zugriffsspezifikation (p ubl i c, private, protected ) be sitzen :

c l ass M~tarbe~ter e xtends Person {

p r i v a t e String firma ;

private d ouble a lter ; 1/ überschreiben von alter aus Person

pub li c Mitarbeiter ( String n , double a , String f ) 1

s uper( n ) ; firma '" f ;

231 VererbllllR

11 Überschriebene Variante angesprochen

}

11

alter = a ;

s uper . a l t e r (int) a l ter ; 11 super-Zugriff auf Erbe

Bei Wertzuweisungen in der Unterklasse oder über ihre O bjek te wird das über­seh rtebene Attribut der Unterklasse verwe ndet. Dennoch kann (wie im Bei spiel) mit­tels s upe r -Refe renz: super .aUribu tna me auf da s geerbte Attribut im Unterklassen­

Codmg wetterhin zugegriffen we rden. Alle rd ings sollte von diesen technischen ;\lög­lichkcitcn nur sparsam Gebrauch gemacht werden. Attrib ute seien i.d .R. privateund werden nicht d irekt vererbt.

Inte ressant ist di e nunmehr erhaltene Symmetri e hins ichtlich der t hi s - und super­Mechanismen in java (Tab. 13.2):

this. super .

Selbstreferenz 0 1ic rklasscn-Refe renz

t his( ) super ( )

Aufruf ei nes Konsuukrors der Aufruf ein es Konstruktcrs derKlasse selbst Oberklasse

Tab. 13.2: Symm etri e der this- un d super-Mech anismen

13.4 Abstrakte KlassenEine Klasse nhierarchie ist e ine spcztaüstc ruogslucrarclnc: An der Spitze stehen all­ue meine; eher abstrakte Begriffe, die d urch ko nkre te re Begriffe spe zialisie rt werde n.Eve ntue ll repräsentieren Basisklassen so allgemei ne Begriffe , dass von ihnen garkeine rea len konkreten Exemp lare vorko mmen [O ES051. Erst für d ie Unterklasse nJassen sich konkret e Exe mplare finden . So ist im bcmebhchen Kontext der BegriffPerson so allgeme in, dass sich in Bet rieb kein e "blogcn" Personen finden: Stets tre ­ten d iese in e ine m konkret e ren Bezug als Angeste llte , Kund en, Berater crc. auf.

Den noch sind auch abst rak t gehaltene Bastskla ssen sinnvo ll, da sie e ine n hinre i­che nd allgem einen Einstieg in e ine sich verzweigend e Vere rbungshie rarchie darstel­len. O hn e die Bastsklasse hingen die davon ausgehend en Zweig e des Verer bun gs­baumes evenrue ll un verbunden "in der Luft". Zugleich werd en in der Basisk lasse be ­reits Methodenschnittstellen gesammelt , die erst in den Unterklassen spezifisch imp­lementie rt werden.

In Java werden abstrakte Klassen durch das Schlüsselwort abstract de­klariert. Abstra kte Klassen enthalt en beiichig s-iele als abs t r act deklar ierteMethoden. Abst rakte Methoden we rde n nur mit ihrem Methodenkopf(Schnittxtcllc ) deklariert, enthalten aber tseine /lIIp /emell tiel'l lllg . (Konstrukte­rcn dü rfe n nicht abst rakt sc in.)

Vererhl/ IIR 235

Daher k önnen vo n abstrakt en Klassen leeine Ohjel'le instanziiort werden - da nichtdefiniert ist , wie d iese s ich hei m Aufruf e iner abstrakten Methode ve rha lten sollten.

Als Beispiel diene d ie abstrak te Basjsklass~ Kon t o . Ko nk rete Konten kommen nurals Giro- oder Sparkonto vo r, e rst für d iese ist definiert, inwieweit Abbcbcvorgäogcbei Cbcrz tchc n des Kontos zugelassen sind . Somit ist die Meth ode a bheben () nurabstrakt (o hne Implementierung) in der Bastsklasse Konto deklariert .

abstract class Kon t o ( 11 enthalt eine abstrakte Methode

private String name ; private int kontoNr ;

p rivate double saldo ;

public Konto( String n , int kn ) { name - n ; kon t oNr - kn ;

public void setSaldo ( double betrag) {saldo betrag ; I

public doub le getSa ldo( ) { return saldo ; }

public void einzahlen( d oub l e betrag) 1 saldo +", betrag ; }

p ublic abstract boolean abheben( double ge ) ;

11

Den Versuch, e in konk retes Konto-O bjekt zu erzeugen, weist de r Compile r ab mitFehlermeldung : Kon t o is abs t r a c t; c annot b e fns t a n t.La t e d .

Von abstra kten Klassen kann geerbt we rden . Eine abstrakte Klasse kann durchausau ch ntchr -abstrakte Methoden enthulrcn. Diese we rde n (wie bei nicht-abstrakt enOberklassem an ihre Unte rklassen vererbt. Die nicht-abst rakten vere rbte n Methodenkönnen in den Unte rklassen direk t verwe ndet we rde n. Auch die abstrakten Mctho­den we rden vererbt.

Die abstrakte Klasse Konto ist nicht Instanzti e rbar. Den noch verfügt sie u.u. überAttribute , nk-h t-abstraktc Me thoden un d e ine n Konxtruktor, der von ihren Unrcrklas­

sc n mittels super () aufgerufen we rde n kan n. Abstrakte Klassen /""ÖlIlICII somit ei ­nen Ko nstrukto r besitzen. Den n auch vo n abstrakten Obe rkla ssen we rden bei derInstanzücnmg ihrer Unte rklassen-O bje kte automatisch O bjekte im Spe icher angelegt.In d iese n we rden die in der abs trakten Klasse eve ntuell vorhandenen Attribute ind i­vidue ll für jedes Unte rk lasse n-Objekt ve rwa ltet.

vtcbt-obstratae Unterklassen abstrakte r Oberklassen müssen alle geerbte n abstraktenMethoden konk ret überschreibe n - andernfa lls sind auch sie abstrak t un d müssenexplizit als abstract gekennzeicbnet werden .

Eine nicht-abstrakte e rbende Unter k lasse muss alle geerbten abstrakte nMethoden durch ntcbt-atxtratse .l1t'lhodel l iiberschreiben und mit hu ple rnen­ttc rung versehen . Durch das Schlüsselwor t abs t r a c t erzwingt d ie Oberklus­se da s Übe rschreiben in e iner nicht-abstrakt en Unte rklasse .

Vorsicht: \Venn man eine r abstrak ter Oberklasse e ine weitere abstrakte Methode hin­zufügt , invalidtcrt man alle bisherigen Unte rklassen. Das Hinzufüge n eine r nicht ­abstrakten Methode mit Dcfault- Implcmenticru ng ist jedoch meist prob lemlos .

236 Vererb llllR

Die nicht abs trakten, tontaetcu Klassen Gi rokonto und Spa r konto e rben vonKonto und übersch reiben die ubsrakte Methode a bheben () durch spezielle aus­implementierte Versionen: Ein Sparkon to darf nicht überzogen, beim Girokon to derDispositionsrahmen n icht überschritten werden.

c1ass Girokonto extends Kon t o { 11 konkrete Klasse

1/ konkrete Klasse

private double dispo ; /1 negativer Wert

public Girokonto ( String n , int kn , double dsp

super ( n , kn ) ; dispo = -Math . a bs (dsp) ;

publ i c boolean abheben( double betrag 1

double test = getSaldo()-Math .abs(betrag) ;

if( test< dispo t return false ;

else { setSaldo( test) ; return true ;

I

1/ weitere Methoden

c1ass Sparkonto extends Kont o

private double zinsSatz ;

public Sparkonto ( String n , int kn , double zs )

super ( n , kn ) ; zinsSatz - z s ,

public boolean abheben ( double betrag 1

double test = getSaldo() - Mat h .abs(betrag) ;

if( test< 0 .0 ) { return false ; I

else { setSaldo ( test) ; r e turn t r u e , I

I

11 weitere Methoden

Abstra kte Methoden dürfen nicat prirat sein - so nst kön nten sie niemals übersch rie­ben und imp lem entiert werden , Auch statische abstrakte Methoden sind unzulässig­sonst kö nn te mall die se ja dire kt auf der abstrakten Klasse aufrufen. Abstrakte Mc­rhoden der Oberklasse dü rfen nich t mit super aufgerufen werden. Eine abstrakteKlasse kann jedoch stat ische implementie rte Methoden enthalten - lind diese sindals Klassenmethoden durchaus direkt auf der ab strakten Klasse aufrufbar.

Eine ab strakte Klasse darf auch /11/1' abstrakte Methoden enthalt en - und stellt danneine reine Schnutstellenbeschreibnng aus Methodenköpfen dar, die durch Unterklas­sen zu imp leme-ntiere n ist. Rein abstrakte Klasse dienen z.B. in C++ zur Interface­Definition. Java besitz t dafür ein ech tes Interface-Ko nzept (Kap itel 14).

In der UM!. wird der Name eine r ab strakten Klasse leursir gesetzt ode r die Bezeich­nung ahstrutet hinzugefügt (Abh, 13.4),

Vererhl/ IIR 23 7

Unte rklassen dürfen konk rete Methoden abs trakt überschrctlx-n. so dass in Unter­klassen zusä tzliche abstrak te Methoden auftreten dürfen Lind es zusätzliche ab strakteUnterklasse n in eine r Klassenh ierarchie ge be n könnte. Dies ist jedoch teein guter Ar­chitckrur-Sril. Abstrakte Verallgemeine runge n sollten als Basisklassen in der Klassen­hierarchie hoch angesiedelt se in, konk rete Spez ialisierunge n tief Eine ab strakte Klas­se d ient als stabile Vorlage für die Able itung konkreter Unterklassen und ste llt abs­trakte Methoden zum Überschreiben bereit: Für spezialisierte Unterklassen ist seman­tisc h klar, welc he Funkrionalirdt ko nkret erforde rlich ist. Die Implementierung wirdquasi b is zur Unterklasse aufgeschoben. Somit sollten abstrak te Klassen immer Ba­stsuassen se in bzw. hoch angesiedelte Oberetassen.

13.5 Finale Klassen und MethodenUnterklasse n können vo n Oberklassen erbe n und durch Übe rschre ibe n d ie Wtr­ku ngsweise gee rbter Metho den verä nde rn. Allerdi ngs kann e ine Oberklasse auchverhinde rn, dass vo n ihr gee rbt wird , oder da ss einzelne geerbte Methoden in Ln­tcrklasscn übersch rieben we rde n. Durch da s Sc-hlüsselwort fina l we rde n "e ndg ül­tige" e inzelne Methode n ode r Klassen deklarielt :

Als final de klarierte Meth od e n dürfe n in Unte rklassen nicht üherscbriebenwerden. Vo n final deklarierte n Klassen dürfen keine Unterelassen ahp,eleilel

werde n. Sie markieren da s Ende e ines v erer bungszwelges. Die Kennzeich ­nung fina l ver hinden Vererbung bzw. das Überschreiben vo n Klassen bzw.Methoden , d ie dafür nicht geeignet sind . Dadurch wird das Unterlau fen vonSicherhe its- ode r Design regeln durch Unterklassen verhindert.

// Finale Klasse : Keine weitere Unterklasse ableitbar

f i nal class Fe s tzin skonto ext e nds Sparkonto { / * */

class Re n t enkont o e xtends Spar konto (

// Finale Methode : einzahlen() nicht überschreibbar

final pub l ic vo id e i n za h len ( double ge ) { / * */ )

/ / ...

Finale Methoden dü rfen nicht a bstrakt sein - sonst kön nten sie niemals tmplemen­tiert we rden. Finale Klassen dü rfen so mit kein e abstrakten Methode n e nrhalren , d .h.nicht ab strakt se in. Konstrukto rcn dürfe n nicht fina l se in. Ein Vortei l finaler Metho­den ist Geschw ind igke it - der Com piler ge ner iert einfache ren und schnel leren Byte­codc, wenn fe ststeht, dass es kein e we itere n Unterklassen ge be n wird .

Eine java-Obcrklussc kan n de n VC/'('r {)l/ lIgsm rgm lg beeinf lussen [MER04]: Sie kanndas Überschreiben verhindern d urch Ke nnzeichnung als f inal und sie kann dasÜbe rschreibe n erzwinge n d urch Kennzeichnung als abs tra c t. Finale Methode ndü rfen in Unterklassen nicht überschrieben werde n . Abstrakte Methoden dagegenmüssen in nicht-abst rakten Unterklassen ülx-rschncbc n we rde n .

23 8

Anwendung der Mechanismen

Vererb llllR

Die Tech nik de s Überschreibens im Vere in mit abstrakte n und finale n Metho den er­laubt die vorlage n-artige vergabe e ines grundsätzliche n Ablaufs (Abfolge von Ope­rationon in fester Reihenfolge ) durch d ie Oberklasse. desse n Bearbeitungs-Detailsjedoch durch Cnrcrklasscn flexibel an deren Bedürfnisse angepasst werden können.Man spricht deshalb auch vom i emptate. öesign-Pauem.

Das fo lgende se hr schematische Beispiel verde uthehr die Logik:

abstract class Konto

publ~c f~nal void pruefe() (

IO .writeln( " Pr ü f u ng beginnt " ) ;

getDaten ( ) ;

pruefeRisiko ( ) ;

setzeDispo ( ) ;

public void getDaten( ) I I O. wr ite l n ( " Ku nde befragt " ) ; )

public abstract void pruefeRisiko( ) ;

public abstract void setzeDispo( ) ;

class Girokonto extends Konto {

public void getDaten( ) I IO .writeln( " St r e ng befragt ! " ) ; I

public void pruefeRisi ko(

public void setzeDispo( )

I IO .writeln( " Ei n korrune n ? " ) ; I

IO .writeln( " 2 *Ei n korrune n" ) ; )

IO .writeln( "En t f ä Ll t" ) ;

IO .writeln( " St e t s 0 " ) ;

class Sparkonto extends Konto {

public void pruefeRisi ko(

public void setzeDispo( )

Die finale Methode pruefe () legt die gru ndle genden Schritte des Algorithm us undihre Reih enfolge in der Oberklasse un übcrschrcibbar fest , überlässt jedoch die Dc­tail-Ausprägung einiger ode r aller Schritte den Unterklassen . Die Unterklassen mü s­sen einzelne oder alle Teilsch ritte de s Algori thmus durch Übe rschreiben der bet ref­fen den (zuminde st abstrakten) Metboden anpassen; auch Oberklassen-Methoden mitDcfauh-Implcmcnticrung könnten an gepasst werden. Die Grundstruktur des Algo­ritbmus (da s Tc mplatc) ist jedoch nicht verände rbar, da dieser in einer finalen Mc­thodc angesiedelt ist. Die Oberklasse und ihre Methode pruefe () legen geme in­samc und unveränderliche Vorgaben fest und die nen als Tempiare für die erbe ndenund überschreibenden Unterklassen.

Wird die geerbte Methode pruefe () der Oberklasse Konto au f e inem Unterklus­sen-Objekt aufgerufen. so we rde n dabe i stets die übersch riebenen Methoden­Varianten der Unterklasse verwendet . Man spricht auch vo n einer 11l/'(! l -SÜm cf Con-

Vererhl/IIR 239

tro! zwischen Ober- und Unterklassen. Der Aufruf vo n pruefe () au f einem Giro­ko n t o-Objekt liefert die Ausgabe:

Pr ü f u n g beginnt Streng befragt! Ei n komme n? 2*Einkommen

Natürlich ist au ch eine unbe abs ichtigte Verwe ndung des Mechan ismus denkba r. AlsOberklassen gedachte Nicht-Te mplatc -Klasscn sollten deshalb keine Aufnife öffentli­che r, d. h. übersc hreibbarer Methoden im Cod ing ihrer eige ne n Methoden e nthalte n!Statt de ssen sollten ihre offentliehen Methoden nur private , d.h. nich t überschreibba ­re e igene Methoden aufrufen! Auf d iese \X.'eise kön nen keine ungewollten v erhat­rcnsä ndcruogcn der Klasse d urch Übersehretben ihrer öffentlicher Metboden entste ­hen .

Spezie ll gilt: Der Mechan ismus sollte nicht bei Konst rukteren verwendet werden.Oberk lasscn-Ko nsrruktorcn sollten kein e überschre ibbaren Methoden ihrer Klasseaufrufen • an de rnfalls isr d ies exp lizit zu dokumenti eren!

13.6 Die Klasse Object

Die Systemklasse Obj ect (aus java . l a n g ) ist Basisklasse der gesamten Java ­Klasse nhierarchie C'Murrcr aller Klasse n"). Jede Jav a-Klasse erb t automatisch von de rKlasse Object und besitzt diese als Oberklasse.

Eine [aru-Kiassenhterarcbie ist immer ein Baum mit Object als W'u rze!kft ls­se, o hne dass dies explizit im Codin g zu ve rmer ken wäre Der Comp iler füglein implizites e xt ends Ob j e ct in de n Kopf jeder Basisk bsse ein.

Auf diese Weise erbten be reits alle unsere Klassen von Object , ohne das s uns diesbewusst war. Obj ect isl e ine kon krete Klasse, die einige Method en rererht. Diesestehen jeder Java -Klasse zur Verfügung, um d irekt verwendet oder zweckd ienlichübers chrieben zu werden. Dazu gehören auch toString () und finalize (): Alswir d iese in e ige ne n Klassen implcnu-miertcn , überschrieben wir tatsächlic h die vonObject geerbte Fassung. Ebenso die Klasse String: Sie überschreibt die geerbteMethode equals () mit einen tcxt uelle n Vergleich zweter Zeichenketten. Für De­tails zu Object verweisen wir au f [SUN05C]. Im Kap itel 19 wird au f einige ihre r Mc­thodcn näh er eingegange n .

Dass jede Java-Klasse von Obj ect erbt, zeigl folgende Demonstration.

c l ass Ha tNi x I 11 Aufruf geerbter Object-Methoden :

publie statie v o i d rna i.n ( String [ J a r g s ) I

Ha tNix hn ~ ne w Ha tN ix {) ;

IO .writeln{ "Hash : " + hn . hashCodeO + " " + h n . t o S t ring() ) ;

IHa.s h : 4072869 Ha t Nix@3e 2 5a 5- Kon s o l e -

210

13.7 Verwendungsprinzipien

Vererblll lR

Vererbung ist ein mächtiges Konzept de r Wiederverwendung und Stru kruncrung vonSoftware und ermöglicht ein übersichtliches Programmieren im Grossen . Dennoc hmuss auch diese s Kon zept mit Bedacht eingesetzt werden , Objektorientierte Analyseund Design von Software sind eine Kunst für sich IOES051, so dass wir nur wenigekritische Pun kte ansprechen.

13.7.1 Kopplungder Unlerklassen anOberklassen

Die Unterelassen sind 1'0/1 ih ren Oberelassen ahhällRig und auf diese angewiesen,sofern sie geerbte Elemente einsetzen. Die Unterklasse erbt Schnittstelle und lrnple­mcnrterung der Oberklasse - und muss sich darauf verlassen, dass d ie Schnittstellestabil bleibt. Es besteht eine einseitige Beziehung zwisc he n Ober- und Lnrerklassen:Nur die Unterklasse "kennt" ihre Oberklassen. während e iner Oberklasse nicht anzu­sehen ist, welche Unterklassen von ihr abgeleitet sind , oder in Zukunft abgele ite twe rden. Die Unterklassen erben von ihre n Oberklassen stets auch deren Fehler undSchwächen IBL0 041.

Somit müssen ÄlldenflJgell an oterutassen sehr vorsichtig vo rgeno mmen werden,da sie das Fundament sind , au f dem an dere Klassen und ganze Projekte aufbauen.Eine tnraiidierung "Oll Unterielassen muss vermieden werden, Jede d irekte ode r in­direkte Änderung an der öffentlichen Schni ttstelle der Oberklassen lind deren Funk­tionsweise kann sich auf alle Unterklassen auswirken - und dazu führen , dass sichdie Verha ltensweise n de r Unterklassen verändern oder nicht mehr gewährleistetsind . \Vflrde eine p ub j.Lc-Obcrklasscnme thode in einer neuc ren Version p riva t edeklariert, so wären wahrschei nlich schlagartig alle Unterklassen lnvalidicrt undnicht mehr kom pllicrbar. Eine Klasse als potent ielle Oberklasse zu e ntwerfen zwi ngtzu einem sehr sauberen Design. \X'e nn sich eine Klasse nicht als Oberklasse eignet,so sol lte sie final sein, um Vererbung vo n ihr konsequent zu verhindern. Bei de rTeam-Entwickl ung grogcr Pro jekte tragen somit die Entwickler zentrale r Klasseng rogc Ve rantwortung.

Die blofk Erweiterung e iner Oberklasse durch zusiitzliche Attribute und Methodenist dagegen meis t unproblematisch für d ie Unterklassen .

Bei der Modcllierung vo n Klassen und noch viel mehr bei der Entwicklung von Ve r­e rbungss tru kturen lasse man sich vo n den Stru kturen der rea len , zu modellierenden\'(-'elt leiten - und weiche davon nicht ab,

13.7.2 semantische Integrität wahren

Geerbte Oberklassenmethoden kön nen in Unterklassen überschrieben werden. Da­bei hat man technisch alle Freiheiten im Rahmen de r Methodenschnittstelle.

Allerdings so llte auch d ie übcrscbrtcbcnc Version die Semantite (inhaltlichen Sinn )der ursprü nglichen Oberelassenmethode heu-abrcn: Die Unterklasse tritt auf als eineSpezialisie rung ihrer Oberklassen und sol lte d iese sinnvoll vertreten kön ne n. Unter­klassen so llten sich bczüglk-h überschriebener Methoden sem antisch we iterhingru ndsätzlich verhalten wie ihre Oberklassen.

Vererhl/IIR 21 1

Ein Beispiel: Ein Anges tellter ist ein spezieller Mirarbeite r. Insofern sollte die über­schri eben Methode getlnfo () von Angestell ter ebe nso wie in Mitarbei tereine n Date n-St r i ng liefern - und nicht eine n vö llig andere Fun ktion en bewirken.

Dem Compiler sind semantische Prinz ipien egal - er ko mpiliert au ch Verst üfk' dagc­gcn. Jedoch wird das Verständnis und d ie Wartbark en einer Klassen hie rarchie er­schwort, wenn da von abgewichen wird. Zudem ist Wahrung de r semantischen Inrcg­ntä r betm Metbodenüberschreiben Grundvora ussetzung für de n sinnvollen Einsa tzvon Polymo rph ie (Kapitel 14).

13.7.3 Vererbung versus Assoziation (Ist einversus Hat ein)

Bei inhalt lich en Beziehungen zwischen Objekten lassen sich zwei grundsärzttch ver­sc hiede ne se mantische Relationen untersche iden:

Die Ist-ei1l-Hcziehung: In unseren Beispiele n ist [cd ...-r Angestellte ein speziellerMitarbeiter und kann als solcher auftreten. Der Begriff Angestellter ist eine Spezia li­sieru ng und Erweite rung des Begriffs Mitarbeite r. Vererb/IIII{ stellt d iese Beziehungsemantisch absolut korrekt dar: Die Unterklasse Angestell t e r erb t vo n der Ober­klasse Mitarbei ter deren Schnittstelle , passt s ie durch Übe rsch reiben an spez ielleUnterklassen-Bedingungen an und e rwe itert sie um Untcrklassc n-spc zlflschc Ele­mente. Im Fall der !st-ei ll-Ikziehu ng ist Vererbung das richtige Mittel und bringt ver­srändhcbes Codi ng hervor.

IIllt-e i" .Ueziehung: Ein Angestellter bat ein Geha lt. Eventu ell setzt sich dieses ausmeh reren Ante ilen zusammen. So mit w ürde man eine geeignete Klasse Gehal tform ulieren. Offensichtlic h ist ein Angestellter kein Gehalt, sondern hat ein Gehalt.Die Klasse Angestellter ist keine Spezialisierun g de r Klasse Gehalt. Som it wä rede r Einsatz von Vererbung hier semantisch falsch und sollte nicht erfo lgen. Vielmehrist Assoziation d:IS semantisch an gemessene Ausdrucksm ittel. um das Zusam men­wirken von Angestellter lind Gehalt zu modellieren. Die Klasse Angestelltersollte somit u.a. über ein Attribut vom Typ Gehal t verfügen :

class Gehalt { r- ." "/ I

class Angestellter 1 private Gehalt 9 ; /' ... */ I

Im Fall de r l s t -ei1l-Beziehung ist l 'ererlm lll{ das Mittel de r Wahl und bringtverständliches Ccxling hervo r. Zur Darstellung einer ttat-etn (Ganzcs-Teil-)Beziehung ist jedoch Assoz ia tion das semantisch ko rrekte Mind.

13.7.4 Warum keine Mehrfachvererbung?

Jav a lässt nur Einfachvererbung zu - jede Unterklasse hat nur eine direkte Oberklos­se. Andere Sprachen wie C++ erlauben Mehrfachvererbung - und au ch zur Be­sc hre ibung der Realität sche int Mehrfachve rerbung erforde rlich : Ein Kind erbt vonva rer und Mutter , e in Klavier ist Möbelstück lind lnsmuncnr zug le ich.

Dennoch hat man sich in java bewusst gegen .Heh!j"achl'ererhl/ Ilg entsch iede n:

• Mehrfachvererbung wird in der Prog rammierpraxi s seltene r verwendet , als manvermuret . Zudem macht sie Klassenhierarchien unübersichtlich.

212 VererbllllR

• Mehrfachvererbung ver langt Compile r un d Laufzeitsystem hö here Leistung en ub ,sie e rhöht den Speiche rbedarf vo n Programmen und macht diese langsamer.

• Mehrfachvererbung führt zum Raurenproblem.

Das Ra li iell p m blem ist in Abbildung 13.3 form uliert. Es liegt e ine IYIll lellji"jrmige Ver­erbuugshierarcbie vor. Mehrfach vererbung bedeutet für d ie Unterklasse U2, d;ISS dieElemente meth () und wert der Oberklasse Ba s i s doppelt vererbt werden - ei n­mal via Unte rklasse Ula un d ei nmal via Unte rklasse Ulb. Welcher \Veg soll der gül ­tige sei n? Die Methode meth () oder das Attribut wert könnten in den UnterklassenUla und Ul b unte rschiedlich üb ersehrleben werden. Welche der Varianten soll anU2 vererbt un d dort beim Aufruf verwend et werden?

Natürlich ist das Rautenproblem lösbar , wie die Sprache C++ beweist. Allerdings nurdurch deutlich e rhö hte n syntaktische n un d technisch en Aufwand . Zur Modcllic rungeiner Mehrfachvererbungs-Scmantik steht in Java deshalb das Interface- Konzept alsvollwertiger Ersa lz zur v erf ügeng (Kapite l 14).

class Basis Ipublic int wert ;publ i c int meth (i nt n)

Iclass Ula e xtends Basis I

public int meth (i n t n)Iclass Ulb extends Basis I

publ i c int meth {i nt n)

class U2 e xtends Ula , Ulb

11

{ /, ... " / )

I / ....../ )

/ ..... / )

Ul aint lllcth( )

Basistnr mct!J( )

im wert

O Ul hint mcrhr )

U2

Ahb . 13.3: Rautenproblem der Mehrfachvere rbung

13.8 Abschließendes Beispiel- KontenverwaltungWir demonstrieren Verer bungstechniken an e ine m Ban kbeispiel (Abb .13.4): Ver­schiedene Arten von Konten so llen verwalt et werden. Die abstrakte BasisklasseKonto stellt e in ige konkrete und abstrak te Methoden zur Verfügung. Objekte sollenfür ko nkre te Kontotyp en Giro-, Spar- und Festzinsko nto erzeugt werden, die durchdito' Klassen Gi rokonto, Spar konto und Fest zins konto abgebi lde t werden.

Aus den Unterklasse n werden Obcrklassen-Ko nstrukro rcn aufgerufe n un d mit Wer­ten versorgt. Durch die stat ischen Attribut e z aehlerGiro in Girokonto un dz aehlerS par in Spa rko n t o wird die Zahl der Girokonto-O h jekte ab 101 bzw.der s par- und Fe stzinskonto-Objekte ab 201 hoc hgezählt . Die Kontonummerbestimmt sich aus de m stattsehen z ählcrwerr : Alle Giro konto-O bjekte haben dieKontonummer zaehlerGiro, alle Sp a r - lind Festzins konto-O bjekte die Kon­tonummer zaehlerSpar. In Kapitel 14 werden die Objekte in e ine m Array an der

Vererhl/ IIR 213

Indexposition gespeichert. die der Kontonummer en tsp richt. (Natürlich reichen d ieKontonummern bei zuviel Girokonto-Objekte n nicht au s - abe r das so ll uns ind iesem einfachen Beispiel nicht srören.)

KOl1tO

pri\'31<: String n.unc

pri\'31<: im konto:"r

pri\'~I<: douhl<: sald"

pu[,l ie K()nt,~ Sl,ing n, iru kn, douhle "d )

puhl ie \-"id ~'inzahl<,n( douhle hl,:lr~g )

I'uhlk' d')lJhle gdS:,ld,>()

I'uhlk' , 'o id sclS,<!d,>( douhle 1"'lr"g )

publk- Slring g~'t"'amd)

publk- int gell':ol11<>1"11:)

ahslr dct puhlie hoolean "hhd",n( douhle h<,tr~g )

a bstr act publk- void lil1"<,:nO

L;>

Girokonto Sparkontopnvau- double dhp<l ['ri""w douh!<' l.in"S'lll

pnvau- boolcan ucbcrzogcn ['ri""w "lat i,' im 1"<,h!<'rSp,,r - 20)

pri\'at~' I'l<M,!<'an lu))"eh ['uhk Sp:.<rkont'>( Strin).: n. douhle- 'd.

pri\'at~' double 'olll.in" douhle- I" )

p ri\'at~· "t31k' inll.'K,hle-r(iiro· tut puhk Slr in,\: t ' ~-;t rin,l:()

puhlic (;irokonto( Slrin,l: n. double "d. p"hli,' Il<l< ,le-an ahhd",n( douhle 1"-1r"" )

douhle- di"p. douh!<' SI. ) p"hli,' \-" id I.in",-·n()

puhlte Strin,\: t,Nrin,\:O~puhlte hoolcan ahhd".-nt double I"-'lra,\:)

p ubh... "oid l.in",-'n(J Fcstzinskoutopri"at~· void dK'~'kO private- int laufl,<:il

private- int ah).:dauk·IlL'Zd

puhlk- F<'''lZinskonto( SIrin).: n.douhle- sJ. douhk· 1.,. int 11. )

publk- Slring t,Nrin,,()

p"hl i... I l< ~ ,le ~ n ahhd",nt douhle 1><-1r",I: )

p"hl i... \uid zin""nO

Abb. 13.4: Klassenhierarch ie Kontotypen

Ik im Giroko nto darf der Kon tostan d auc h negat iv we rde n; allerdings wird ein Ah­hcbcvorgang nur au sgeführt , wenn der Divpoxitionsrahmcn nicht übe rschritten wird .Die booleschen Marker ueberzogen Lind zu Hoch zeigen an, d;ISS der Kontostandnegativ bzw. deutlich im Plus ist. Darufhin kön nte e in Sachbearbe iter Kunden­Empfehlungen aus sp rechen. Die Marker we rde n durch d ie private Methodechec k () be im Aufruf von toSt ring () gesetzt. Für ein Girokonto gibt es keine

211 Vererb llllR

Hab enzinsen. Ik-im Überziehe n werde n Sollzinsen fällig, die sich au s dem aktuellen(negativen) Ko ntostand und sollZins berechnen.

Beim Spa rkonto sind Abhe bevorgänge erlaubt, aber der Kontostan d darf nich t nega­tiv werden. Es werden Zinsen gezahlt , d ie mit dem Attribut zinsSatz berechnetwerden. Ein Festzinskonto soll während de r laufzeit (in Jahren ) nicht angreifbarsein , Einzah lun gen s ind jedoch erlaubt. Bei jeder jährliche n Zinsausschüttung wirddas Attribut a bgelaufeneZeit um 1 erhö ht. Erst wenn a bgelaufene­Zei t==laufzei t kann vom Konto abgehoben werden, jedoch darf der Konto­stand n icht negativ werden.

Die Methoden abhebe n () liefe rn einen boolcschen \Ver! zur ück der anzeigt, obder Abhebevorgang durchfü hrbar wa r. Die Unte rk lasse n überschreiben d ie gccrlxcnabstrakten Methoden abheben () un d zinsen () in se mant isch spezifischer Weise.Die Klasse Festzinskonto nutzt mittels super-Aufruf auch die von Spar kontogc..rb tcn Fass ungen.

Die Klasse n ränge n ke ine Konsolenausgaben. Jedoch stellen sie für Ausgabefunkrio­ncn anderen Klassen in der Mt...thodc toString () alle Daten als String zur Ver­fügung; dabe i werde n Geldbe träge auf zwei Kommastellen gerundet.

abstract c l ass Konto {

private St ring na me ;

private double saldo;

// abstrakte Oberklasse

pr i va te i nt ko ntoNr ;

i nt kn , double sd )p ublie Konto (

name = n ;

String n ,

kont oNr = kn; saldo = sd ;

p ublie void einzahlen( dou ble be t r a g )

saldo - saldo + Math .abs( b e t r a g ) ;

p ublie Str ing ge t Name ( ) r e t urn name ; I

p ublie int getKontoNr () return kon t oNr ; I

p ublic double ge t Sa l d o ( ) t return saldo ; )

p ublie vo id setSa ldo( doubl e b e t r a g ) sa ldo - betrag ;

abstract publ i c bo o lean abheben ( d ouble betrag ) ;

abs tract public void zinsen ( ) ;

class Girokonto extends Kon t o

pr ivate double dispo ;

private boolean z uHoch ;

private double sol lZins ;

private bo o lea n ueberzogen ;

pr ivate statie int zaehlerGiro ~ 101 ;

publ i c Girokonto{ String n , double sd , // eine Zeile!

d ouble d i s p , double sZ ) {

super ( n , zaeh lerGiro , sd ) ;

zaehlerGiro++ ;

Vererhl/ IIR

dispo = -Math .abs( disp ) ; sollZins sZ ;

215

public boolean abheben( double betrag)

double test ~ getSaldo() - Math .abs( betrag ) ;

if( test< dispo) return false ;

else ( setSaldo( test ) ; re t u rn true ; f

public v oid zinsen()

if( getSaldo() < 0 .0 // nur Sollzinsen

setSaldo( getSaldo() *(l + sollZins) ) ;

public String t oString() {

c heck() ;

String daten - "Gi r o kon t oda t e n: \ n";

date n += " Ko nt onumme r " + getKontoNr() + " \ n ";

daten ,~ " I n ha be r , getName () , " \ n " ;

daten ,~ " Di s po ~ , dis po , " \ n" ;

daten ,~ " Ko nt o s t a nd ~, IO . round( qe t SaLdo () , 2 I , " \ n " ;

d a t e n ,~ " So l l z i ns s a t z , sollZins , " \ n " ;

daten ,- " üb e r zo ge n , ueberzogen , " \ n " ;

daten ,~ " Ho c h s t a nd , zuHoch , " \ n " ;

re turn daten ,

private v oid c he c k ( ) {

ueberzogen ~ ( getSaldo() < 0 .0 ) ;

zu Ho c h ~ ( getSa ldo() > 5000 .0 ) ;

c l a s s Sparkonto extends Konto

private double zinsSatz ;

private static int zaehlerSpar = 201 ;

Sparkonto(String n , double sd , double zs)

super( n , zaehlerSpar , s d ) ;

za e h l erSpar ++ ; zinsSatz '"' zs ;

public boolean abheben( double betrag)

doub le test - getSaldo() - Math .abs( betrag ) ;

if ( t e s t < 0 .0 ) return false ;

216

else { setSaldo ( test ) ; ret.u rn r rue •

Vererblll lR

publ i c void zinsen ( ) I setSaldo ( getSaldo() * (l+zinsSatz) ) ; I

publ ic String toString () I

String daten"" " Sp a r ko nt od a t e n: \ n";

daten += " Kon t onunune r " + getKontoNr () + " \ n " ;

daten +- " I nha b e r - " + getName() + " \ n ";

da ten += " Kon t os t a nd = " + IO .round(getSaldo() , 2) + " \ n ";

daten += " Zi n s a t z "" " + zinsSatz + " \ n " ;

return daten ;

class Fes tz inskon t o e xte nds Sparkont o (

priva te int laufzeit ; private int abgelaufeneZeit ;

Fea tzinskonto( String n . d oubl e s d. double zs , int lz )

super ( n , sd , zs ) ;

laufzeit "" Math .abs( lz ) ; abgelaufeneZeit 0 ,

publ ic boolean abhe b e n( double betrag l

if( laufzeit> abgelaufeneZeit ) return false ;

return super .abheben( betrag ) ;

publ i c String toString () I

String daten "" super .toString() ;

daten +"'" "Typ Festzinskonto \n " ;

daten +'" "Ge s a mt l a u f ze i t '" " + laufzeit + " \ n " ;

daten +'" "An l a ge da u e r '"' " + abgelaufeneZeit + " \ n " ;

return daten ;

public v o i d zinsen () I super .zinsen() ; abgelaufeneZeit++ ; I

c l a ss Bank 1* ... * /

Die aus füh rbare Klasse Bank so ll Methoden zur Manip ulation der re rscbtedenenKOnlo tJ1X'11 enthalten. Wir möchten die re rscbicdenen Typen in einem Obje krarrayspeiche rn . Dies wirft sofon e in Prob lem auf: Für u-clcben 1)P de klarieren wir Me­rhoden bzw . das Army? Müsse n für jeden Kontotyp eigene Methoden und ein sepa ­rates Array ange legt we rde n? Die mächt ige Lösung hdl~t p()~1"11I011)hie. Mittels des imnächsten Kapite l besprochene n Polymorphie -Konze pts werde n w ir die Ko ntenve r­walt ung zu eine m ab lauffäh igen Programm au sbauen.