Vererbung persistenter Klassen
Vererbung persistenter Klassen
Im Class Builder können Unterklassen persistenter Klassen angelegt werden. Diese Unterklassen sind dadurch ebenfalls persistente Klassen, wobei die Persistenzabbildung der Oberklasse auf ihre Datenbanktabelle(n) übernommen wird. Der Mapping Assistent im Class Builder unterstützt die Vererbung des Mappings. Das Mapping der Oberklassen wird im Mapping-Assistenten der Unterklasse zwar dargestellt, kann aber nicht verändert werden. Ansonsten würde das allgemeine Polymorphieprinzip der Vererbung, dass Unterklassen vom Verwender wie Oberklassen behandelt werden können, verletzt.
Bei der Generierung der Klassenakteure einer persistenten Unterklasse werden die Mappinginformationen und Attribute aller Oberklassen einbezogen. Dadurch ergeben sich für Unterklassen persistenter Klassen zwei verschiedene Arten, wie das Mapping vererbt wird.
Die persistenten Attribute, die in der Unterklasse zusätzlich definiert werden, können in der Unterklasse auf eigene Tabellen, Datenbank-Views bzw. Strukturen gemappt werden. Dabei gilt die allgemeine Regel des Mehr-Tabellen-Mapping, dass die Schlüssel der hinzukommenden Tabellen, Datenbank-Views bzw. Strukturen die gleichen sein müssen, wie die Schlüssel der Tabellen, Datenbank-Views bzw. Strukturen der Oberklasse. Die Schlüsselfelder sind damit in Oberklasse und Unterklasse gemappt. In der Unterklasse werden also zusätzliche Attribute und die entsprechenden GET- und SET-Methoden hinzugefügt, ohne die der Oberklasse zu beeinflussen. In der Oberklasse müssen alle persistenten Attribute gemappt werden.
Ein Sonderfall des vertikalen Mappings ist dann gegeben, wenn die persistenten Attribute, die in der Unterklasse zusätzlich definiert werden, auf dieselben Tabellen, Datenbank-Views bzw. Strukturen wie die Attribute der Oberklasse gemappt werden. Um nun feststellen zu können, zu welcher Klasse ein Tabelleneintrag gehört, muß in einer der Tabellen, Datenbank-Views bzw. Strukturen ein spezielles Feld vom Typ OS_GUID vorhanden sein, dem beim Mapping im Mapping Assistant der Zuordnungstyp Typidentifikator gegeben wird.
Ist eine persistente Oberklasse abstrakt, können dort persistente Attribute ohne konkretes Mapping definiert werden. In jeder direkten Unterklassen muß für die persistenten Attribute der Oberklasse ein Mapping angegeben werden. Die Unterklassen können also auf verschiedene Tabellen, Datenbank-Views bzw. Strukturen gemappt werden. Dabei wird nicht geprüft, ob die Unterklassen tatsächlich auf verschiedene Tabellen, Datenbank-Views bzw. Strukturen gemappt werden.
Die Klassenakteure von persistenten Klassen, die in einer Vererbungsbeziehung stehen, stehen nicht in einer entsprechenden Vererbungsbeziehung. Es gilt weiterhin das Prinzip, dass ein Klassenakteur nur die Objekte der zugehörigen Klassen verwaltet und auch die Objekte der Unterklasse. Dies hat zur Folge, das die privaten Attribute von nicht finalen persistenten Klassen nicht vollständig vor Lese- bzw. Schreibzugriff geschützt sind. Zu schützende Informationen dürfen also nicht in privaten Attributen nicht finaler persistenter Klassen abgelegt werden.
Polymorphie in den Methoden des Klassenakteurs
Die Methoden DELETE_PERSISTENT, REFRESH_PERSISTENT und RELEASE des Interfaces IF_OS_FACTORY des Klassenakteurs verhalten sich polymorph, d.h. diese Methoden können für ein gegebenes verwaltetes Objekt auch am Klassenakteur einer (nicht abstrakten) Oberklasse dieses Objekts aufgerufen werden. Über die übergebene Referenz kann zur Laufzeit der Typ des verwalteten Objektes bestimmt werden und der zuständige Klassenakteur der Unterklasse aufgerufen werden.
Wenn in der oder einer der Tabellen, Datenbank-Views bzw. Strukturen, die auf die Wurzelklasse der Vererbungshierarchie gemappt ist, ein zusätzliches Typfeld (Typidentifikator) vorhanden ist, verhalten sich auch die Methoden GET_PERSISTENT, DELETE_PERSISTENT sowie GET_PERSISTENT_BY_KEY und GET_PERSISTENT_BY_OID des Interface IF_OS_CA_PERSISTENCY des Klassenakteurs polymorph. Dies bedeutet, dass mit dem Klassenakteur einer (nicht abstrakten) persistenten Klasse auch ein persistentes Objekt, das zu einer persistenten Unterklasse der von diesem Klassenakteur verwalteten Klassen gehört, über den Schlüssel gelesen (Business Key oder GUID) bzw. gelöscht (Business Key) werden kann. Dies geschieht durch Delegation an den Klassenakteur der Unterklasse, der über die Information im Typfeld zur Laufzeit ermittelt werden kann.
Zusätzlich bewirkt die Angabe eines zusätzlichen Typfelds (Typidentifikator) die Eindeutigkeit des Schlüssels (Business Key) in der gesamten Vererbungshierarchie. Es ist also nicht möglich, ein verwaltetes Objekt mit einem Schlüssel zu erzeugen, den ein anderes verwaltetes Objekt einer beliebigen Unterklasse, Oberklasse oder deren Unterklassen hat.