Grundlagen der Informatik I “Programmierung”

Grundlagen der Informatik I “Programmierung” Grundlagen der Informatik I “Programmierung”

22.08.2013 Aufrufe

3.8.2 Export geerbter Features Normalerweise werden alle features einer Elternklasse unverändert übernommen. Es gibt jedoch Gründe, Ausnahmen von dieser Regel zu vereinbaren. Manche Merkmale der Elternklasse PERSON machen im Zusammenhang mit der Verwaltung von Entleihern nur wenig Sinn: weder das Todesdatum noch die Nationalität sind von irgendeinem Interesse. Daher sollten diese features von der Klasse ENTLEIHER nicht wieder als Dienstleistungen bereitgestellt werden. Da sie nicht innerhalb der Klasse ENTLEIHER definiert, sondern geerbt wurden, kann man ihre Verbreitung auch nicht durch die Form der feature-Klausel kontrollieren, sondern benötigt eine explizite Export-Vereinbarung. In Eiffel wird dies durch Angabe einer export-Klausel innerhalb der Beschreibung der Vererbungseigenschaften ermöglicht. class ENTLEIHER inherit PERSON export name, vornamen, geburtsdatum end -- feature-Anpassung von PERSON feature straße, hausnummer, stadt: STRING; postleitzahl : INTEGER; ausweisnummer: INTEGER end -- class ENTLEIHER Abbildung 3.29: Klassendefinition mit Export geerbter features Die Angabe des Schlüsselwortes export besagt, daß die dahinter aufgezählten von PERSON geerbten features zusammen mit den neuen features als Dienstleistungen der Klasse ENTLEIHER bereitstehen. Die nicht genannten features todesjahr und nationalität sind nicht mehr benutzbar. Fehlt die export-Klausel, so sind alle von PERSON geerbten features erneut verfügbar. Das Schlüsselwort end beendet Modifikationen der geerbten features. Auch beim Export geerbter features kann es sinnvoll sein, die Weitergabe von Informationen von der Kundenklasse abhängig zu machen. So könnte es zum Beispiel sein, daß die Nationalität eines Arbeitnehmers – ebenfalls ein Spezialfall von Personen – für das Finanzamt aus steuerrechtlichen Gründen von Bedeutung ist, nicht aber für den Arbeitgeber. Aus diesem Grunde erlaubt Eiffel einen selektiven Export geerbter features. Die Syntax ist vergleichbar mit der in Abschnitt 3.4 angegebenen Form für feature-Klauseln: export { Klassenliste1} featurelist1; . { Klassenlisten} featurelistn Die Klasse ARBEITNEHMER in Abbildung 3.30 exportiert an die Klasse ARBEITGEBER – und an alle Erben dieser Klasse– die geerbten features name, vornamen, geburtsjahr sowie alle neu vereinbarten features 20 , an die Klasse FINANZAMT jedoch alle geerbten (und die neuen) features. Zur Vereinfachung der Schreibweise gibt es hierfür in Eiffel (Version 3) das Schlüsselwort all. Es besagt, daß alle features der Elternklasse an die in der Klassenliste aufgezählten Klassen geliefert werden. Fehlt die export-Klausel, so bleibt ein geerbtes geheimes feature geheim und ein exportiertes features wird weiter exportiert. Dieses Verhalten kann jedoch in der export-Klauseln nach Belieben verändert werden, da die Erben einer Klasse – im Gegensatz zu den Kunden – alle Rechte (und Pflichten) ihrer Ahnen besitzen und damit umgehen dürfen, wie sie es für richtig halten. Sie dürfen daher für ihre Kunden ein geheimes feature wieder exportieren bzw. ein exportiertes feature verstecken 21 . 20Wir haben hier der Einfachheit halber die vier Komponenten straße, hausnummer, stadt, postleitzahl einer Adresse in einem Objekt zusammengefaßt. 21Hier gibt es allerdings feine Grenzen, da sonst die Korrektheit des Gesamtsystems verletzt werden könnte.

class ARBEITNEHMER inherit PERSON export {ARBEITGEBER} name, vornamen, geburtsjahr; {FINANZAMT} all end -- feature-Anpassung von PERSON feature adresse: ADRESSEN; gehaltsklasse: STRING; gehalt: REAL is -- Gehalt berechnen do Result := Gehalt aus Tabelle nach gehaltsklasse end end -- class ARBEITNEHMER Abbildung 3.30: Klassendefinition mit selektivem Export geerbter features Diese Koppelung der Vererbung mit dem in Abschnitt 3.4 diskutierten Geheimnisprinzip hat eine Reihe interessanter Anwendungen. Sie erlaubt es, durch verschiedene Erbenklassen auch verschiedene Sichten auf eine Datenstruktur zu ermöglichen und hierüber die unterschiedlichen Zugriffsrechte zu regeln. So gibt es zum Beispiel bei einem Bankkonto die Vorgänge eröffnen, abheben, einzahlen, geheimzahl eingeben, geheimzahl prüfen, geheimzahl ändern, löschen, gebühren einziehen, konto sperren, usw. Nicht jeder dieser Vorgränge darf vom Kunden selbst ausgeführt werden (für die Eröffnung des Kontos sind z.B. einige Vorschriften zu beachten) sondern nur von den Bankangestellten am Schalter und umgekehrt. Andere Vorgänge (Kontosperrung) dürfen nur von Angestellten des Managements ausgelöst werden. Diese verschiedenen Sichten auf ein und dieselbe Datenstruktur läßt sich durch Vererbung auf eine sehr einfache und übersichtliche Art realisieren. Die in Abbildung 3.31 genannten Erben der Klasse BANKONTO stellen jeweils einen Teil der Dienstleistungen der Ahnenklasse bereit und darüber hinaus noch ihre eigenen speziellen features. ✬ ✫ SCHALTER ✬ BANKONTO ✫ ✟✩✟✟✟✟✯ ✬ ✻ ✪✫ KUNDE ✩ ❍❨ ❍✪ ❍ ✩❍ ❍✬ ✪✫ MANAGEMENT ✩ ✪ Abbildung 3.31: Vererbung und Datenkapselung: Verschiedene Sichten auf eine Datenstruktur Eine gewisse Ausnahme von der Regel, daß features einer Elternklasse für gewöhnlich übernommen werden, betrifft Initialisierungsprozeduren. Meist besitzen die Erben einer Klasse mehr Attribute als ihre Vorfahren und auch die Eigenschaften der geerbten features sind oft spezieller als die der Elternklasse 22 . Aus diesem Grunde müssen spezifische Initialisierungsprozeduren einer Nachkommenklasse oft völlig anders aussehen als die der Eltern. Man kann also nicht einfach die Initialisierungsprozedur der Elternklasse erneut zur Erzeugung von Objekten der Nachkommenklasse verwenden. Ist dies dennoch gewünscht, so muß diese Prozedur erneut über eine creation-Klausel als Initialisierungsprozedur der Nachkommenklasse deklariert werden. Ansonsten ist sie nicht mehr als eine gewöhnliche geerbte Routine, die bestehende Objekte ändert, nicht aber neue erzeugt. Vererbung ermöglicht es, Objekte einer Nachkommenklasse auch als Objekte der Vorfahrenklasse zu betrachten. Arbeitnehmer und Entleiher sind insbesondere auch Personen – man besitzt nur einige zusätzliche Informationen über Arbeitnehmer und Entleiher, die man von Personen nicht unbedingt erhalten kann. 22 So muß zum Beispiel ein Arbeitnehmer in Deutschland immer älter als 14 Jahre sein, während für Personen eine solche Einschränkung nicht sinnvoll ist.

3.8.2 Export geerbter Features<br />

Normalerweise werden alle features einer Elternklasse unverän<strong>der</strong>t übernommen. Es gibt jedoch Gründe,<br />

Ausnahmen von dieser Regel zu vereinbaren. Manche Merkmale <strong>der</strong> Elternklasse PERSON machen im Zusammenhang<br />

mit <strong>der</strong> Verwaltung von Entleihern nur wenig Sinn: we<strong>der</strong> das Todesdatum noch die Nationalität<br />

sind von irgendeinem Interesse. Daher sollten diese features von <strong>der</strong> Klasse ENTLEIHER nicht wie<strong>der</strong> als Dienstleistungen<br />

bereitgestellt werden. Da sie nicht innerhalb <strong>der</strong> Klasse ENTLEIHER definiert, son<strong>der</strong>n geerbt<br />

wurden, kann man ihre Verbreitung auch nicht durch die Form <strong>der</strong> feature-Klausel kontrollieren, son<strong>der</strong>n<br />

benötigt eine explizite Export-Vereinbarung. In Eiffel wird dies durch Angabe einer export-Klausel innerhalb<br />

<strong>der</strong> Beschreibung <strong>der</strong> Vererbungseigenschaften ermöglicht.<br />

class ENTLEIHER<br />

inherit PERSON<br />

export<br />

name, vornamen, geburtsdatum<br />

end -- feature-Anpassung von PERSON<br />

feature<br />

straße, hausnummer, stadt: STRING;<br />

postleitzahl : INTEGER;<br />

ausweisnummer: INTEGER<br />

end -- class ENTLEIHER<br />

Abbildung 3.29: Klassendefinition mit Export geerbter features<br />

Die Angabe des Schlüsselwortes export besagt, daß die dahinter aufgezählten von PERSON geerbten features<br />

zusammen mit den neuen features als Dienstleistungen <strong>der</strong> Klasse ENTLEIHER bereitstehen. Die nicht genannten<br />

features todesjahr und nationalität sind nicht mehr benutzbar. Fehlt die export-Klausel, so sind alle<br />

von PERSON geerbten features erneut verfügbar. Das Schlüsselwort end beendet Modifikationen <strong>der</strong> geerbten<br />

features.<br />

Auch beim Export geerbter features kann es sinnvoll sein, die Weitergabe von Informationen von <strong>der</strong> Kundenklasse<br />

abhängig zu machen. So könnte es zum Beispiel sein, daß die Nationalität eines Arbeitnehmers –<br />

ebenfalls ein Spezialfall von Personen – für das Finanzamt aus steuerrechtlichen Gründen von Bedeutung ist,<br />

nicht aber für den Arbeitgeber. Aus diesem Grunde erlaubt Eiffel einen selektiven Export geerbter features.<br />

Die Syntax ist vergleichbar mit <strong>der</strong> in Abschnitt 3.4 angegebenen Form für feature-Klauseln:<br />

export<br />

{ Klassenliste1} featurelist1;<br />

.<br />

{ Klassenlisten} featurelistn<br />

Die Klasse ARBEITNEHMER in Abbildung 3.30 exportiert an die Klasse ARBEITGEBER – und an alle Erben dieser<br />

Klasse– die geerbten features name, vornamen, geburtsjahr sowie alle neu vereinbarten features 20 , an die<br />

Klasse FINANZAMT jedoch alle geerbten (und die neuen) features. Zur Vereinfachung <strong>der</strong> Schreibweise gibt es<br />

hierfür in Eiffel (Version 3) das Schlüsselwort all. Es besagt, daß alle features <strong>der</strong> Elternklasse an die in <strong>der</strong><br />

Klassenliste aufgezählten Klassen geliefert werden.<br />

Fehlt die export-Klausel, so bleibt ein geerbtes geheimes feature geheim und ein exportiertes features wird<br />

weiter exportiert. Dieses Verhalten kann jedoch in <strong>der</strong> export-Klauseln nach Belieben verän<strong>der</strong>t werden, da<br />

die Erben einer Klasse – im Gegensatz zu den Kunden – alle Rechte (und Pflichten) ihrer Ahnen besitzen und<br />

damit umgehen dürfen, wie sie es für richtig halten. Sie dürfen daher für ihre Kunden ein geheimes feature<br />

wie<strong>der</strong> exportieren bzw. ein exportiertes feature verstecken 21 .<br />

20Wir haben hier <strong>der</strong> Einfachheit halber die vier Komponenten straße, hausnummer, stadt, postleitzahl einer Adresse<br />

in einem Objekt zusammengefaßt.<br />

21Hier gibt es allerdings feine Grenzen, da sonst die Korrektheit des Gesamtsystems verletzt werden könnte.

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!