Vergleich von Delphi und Visual C++ - Inhalt

Vergleich von Delphi und Visual C++ - Kapitel 2A
Eine Funktion, die in zwei verschiedenen Klassen deklariert ist, kann dank des Polymorphismus unterschiedliche Aktionen ausführen.
So könnte zum Beispiel das Objekt Fahrzeug aus der oben aufgeführten Klassenhierarchie eine Funktion "FAHR_LOS" definieren,
die jedoch nur das Starten des Antriebswerks bewirkt. Die vererbten Klassen überladen "FAHR_LOS" so, daß Klasse Landfahrzeug
die Antriebsenergie an vier Räder überträgt, während dessen Klasse Wasserfahrzeug diese an eine Schiffsschraube weiterleitet.
Allgemeiner ausgedrückt heißt das, daß die endgültige Implementierung polymorpher Funktionen erst in den Unterklassen im Sinne
der Verantwortlichkeiten der Klassen und Objekte implementiert werden. Unterschiedliche Objekte können beim Aufruf der gleichen
Methoden oder beim Versenden derselben Nachrichten an sie auf ihre eigene, spezifische Art und Weise reagieren.
Diese Flexibilität können Objekte nur deswegen aufweisen, weil sie mehrere dynamische Konzepte kennen und anwenden:
● dynamische Typprüfung
● dynamisches Binden (spätes Binden)
● dynamisches Laden
Statische Typprüfungen während des Übersetzens von Programmen sind sehr nützliche Eigenschaften von Compilern und helfen,
Fehler zu vermeiden. Die polymorphen Eigenschaften der objektorientierten Sprachen machen es aber manchmal notwendig, Typen
erst dynamisch zur Laufzeit zu prüfen und auszuwerten. Zum Beispiel könnte eine Methode ein Objekt als Parameter mitliefern, ohne
daß beim Übersetzen der genaue Typ dieses Objekts bekannt ist. Der Typ wird erst zur Laufzeit determiniert, ist möglicherweise auch
erst jetzt bekannt.
Dynamisches Binden, manchmal auch spätes Binden genannt, verschiebt beim Übersetzen die exakte Entscheidung, welche Methode
aufzurufen ist. Vielmehr wird dies erst zur Laufzeit des Programms genau entschieden. Die Sprachen C++ und Object Pascal
verlangen stets statische, eindeutige Typangaben im Quelltext (strong compile-time type checking). Objekttypen sind direkt zum Typ
der eigenen Basisklasse oder zu einem beliebigen anderen, vorhergehenden Klassentyp des Vererbungszweiges
zuweisungskompatibel. D.h., spezialisiertere Objekte können immer so benutzt werden, als ob sie weniger spezialisierte Objekte
wären. Durch statische Typkonvertierung oder dynamische Typprüfung mit anschließender Typkonvertierung kann aber auch
umgekehrt ein Objekt einer weniger spezialisierten Klasse in ein Objekt einer höher spezialisierten Klasse umdefiniert werden.
Insbesondere bei dynamischer Typprüfung kann der Compiler nicht wissen, welche Klassenmethoden er aufrufen muß. In C++ und
Object Pascal wird die Entscheidung, welche genaue Methode aufzurufen ist, zur Laufzeit getroffen, wenn die Methode mit dem
Schlüsselwort virtual deklariert worden ist. So deklarierte Methoden nennt man virtuelle Methoden. Erst zur Laufzeit des
Programms wird festgelegt, welcher Funktionsrumpf an einen konkreten Funktionsaufruf gebunden wird.
Neben dynamischer Typprüfung und dem dynamischen Binden unterstützen manche objektorientierte Programmiersprachen
zusätzlich das Konzept des dynamischen Ladens. Programmteile werden dabei erst dann in den Arbeitsspeicher geladen, wenn sie
tatsächlich benötigt werden. C++ und Object Pascal unterstützen dynamisches Laden nur in soweit, wie es durch die Betriebssysteme
mit dem Windows 32 - API ermöglicht wird: nämlich dynamisch ladbare Bibliotheken (DLL's) und systemweit einsetzbare Objekte
nach dem OLE2 (Object Linking and Embedding Version 2) Verfahren.
Es ist einleuchtend, daß durch das Ausnutzen der Prinzipien von Kapselung, Polymorphie, Überladen und dynamischer Eigenschaften
Anwenderprogramme einfacher und besser lesbar werden und so letztlich auch leichter erweitert werden können. Ein Anwender
kümmert sich nicht darum, wie eine Aufgabe ausgeführt wird, sondern nur darum, welche Aufgaben überhaupt erfüllt werden
können, währenddessen die Objekte "für sich selbst verantwortlich" sind. So können unter anderem auch viel leichter ungültige
Zustände von Attributen vermieden werden. Hierarchien bieten die Möglichkeit, ein besseres Verständnis des Anwendungsbereichs
zu erlangen und sorgen für eine gewisse Ordnung. Jetzt ist es möglich, lokale Veränderungen in großen Systemen vorzunehmen, ohne
daß globale Modifikationen nötig werden. Besonderes Gewicht erfahren diese Aussagen vor dem Hintergrund, daß 80% Zeit der
Softwareentwicklung nicht mit dem Neu-Schreiben, sondern mit Testen, Wartung, Erweiterung und Fehlerbereinigung bestehender
Systeme verbracht werden [4].
http://ourworld.compuserve.com/homepages/praxisservice/kapit2a.htm (5 of 24) [19.05.2000 15:30:03]