infra:NET Expert
 
×
8.5.3 Anwendungsprogramme und Datenobjekt im IS
Die Klasse ACIpsData dient als Schnittstelle zwischen Daten im Anwendungsprogramm und Daten, die in funktionserweiternden DLL’s benötigt werden. Die Klasse ACIpsData dient im Prinzip als Basisklasse für die eigentlichen Datenklassen, die in INFRA z.B. innerhalb des Buchungssystems benötigt werden.
Zu Testzwecken enthält sie allerdings Arrays für ULONG, DOUBLE und SCString Variablen:
#define MAX_USER_ELEMENTS  20
 
#define MUE
 
MAX_USER_ELEMENTS
 
 
 
SCString 
scsModulName
Aufrufendes Modul
.....
 
 
ULONG
ulArr[MUE]
 
DOUBLE
dArr[MUE]
 
SCString
scsArr[MUE]
 
Die Referenz auf das im Anwendungsprogramm erzeugte Datenobjekt ist bei der Ausführung der Steuerdatei in den Verteilerfunktionen bekannt.
Die ...Arr-Variablen dienen dazu neue noch nicht implementierte Werte zu tragen. Mit C++ lässt sich eine Referenz mit einem sprechenderen Namen auf ein Arrayelement bilden als Element[lIndex]:
  ULONG &ulNeuerWert = ulArr[5];
Damit kann in einer Funktion das Datenelement wie eine beliebige Variable genutzt werden.
Richtig weiter kommt man mit der Datenklasse allerdings erst dann, wenn man neue Datenklassen von ihr ableitet.
Um die Objekte von ACIpsData und den davon abgeleiteten Klassen wirkungsvoll zu nutzen sind einige memberfunctions mit dem Attribut virtual deklariert. Der Hintergrund für diese Deklaration ist ein sauberes Verhalten bzgl. Typecasts und Destruktoraufrufen. Das Attribut virtual bedeutet, dass der Compiler Code generiert, der bei Aufruf einer Methode, deren Adresse einer virtuellen Funktionstabelle entnimmt. Ansonsten setzt der Compiler direkt den Methodenaufruf zur entsprechenden memberfunction ein. Ganz fatale Folgen haben Codesequenzen wie diese:
 
  ACIpsDataDerived *pAD = new ACIpsDataDerived;
  ACIpsData pA = (ACIpsData *) pAD;
delete pA;
 
Wenn der Destruktor von ACIpsData nicht mit virtual deklariert worden ist, wird nur das ACIpsData-Objekt vernichtet. Zurück bleibt eine Hauptspeicherleiche, weil das durch die Ableitung zusätzlich angelegte Objekt nicht vernichtet wurde, mit den allseits unbeliebten Folgen.
Die Schnittstelle zum Interpretersystem kennt nur die Klasse ACIpsData. Übergibt ein Anwendungs­programm eine Referenz auf ein Objekt einer davon abgeleiteten Klasse, benötigt man eine Methode, die unabhängig vom Typ, der durch den typecast entsteht, die ursprüngliche Klasse des Objektes zugänglich macht. Um sicher zu stellen, dass ein Datenobjekt von einer ausreichend „hohen“ Klasse ist, gibt es die Methode QueryIsSubclass(MinClassID), wobei MinClassID der ID der Klasse entspricht, von der das Objekt entweder stammt oder abgeleitet worden ist.
An dieser Stelle muss darauf hingewiesen werden, dass eine vernünftige Nutzung der Datenschnittstelle ein angemessenes Design voraussetzt, sprich eine schlechte Klassenhierarchie wird mit der Zeit zu großen Problemen führen.