Während Softwareentwicklung in den 70er Jahren maßgeblich durch die Anwendung des Prinzips der strukturierten Programmierung geprägt war, wurde in den folgenden Jahren immer deutlicher, daß eine Steigerung hinsichtlich Quantität und Qualität nur unter Zuhilfenahme eines ganz neuen Konzepts möglich sein würde, der objektorientierten Programmierung (OOP). Beim bis dahin angewandten strukturierten Ansatz wird eine Aufgabe in immer kleinere Verarbeitungsschritte aufgespalten. Diese Vorgehensweise wird deshalb auch Top-Down-Ansatz genannt. Sie zeichnet sich dadurch aus, daß Daten im Vergleich zu Funktionen eine untergeordnete Rolle spielen. Im Gegensatz dazu entsteht bei der objektorientierten Entwicklung ein Programm nicht um eine Anzahl von Funktionen herum, sondern wird durch die Verwendung von Objekten geprägt. Objekte spiegeln dabei Elemente des Anwendungsbereichs wider. Sie sind Datenstrukturen (genauer gesagt Instanzen derselben), die ein bestimmtes Verhalten aufweisen, welches durch Funktionen innerhalb der Objekte festgelegt wird.
Die Deklaration des Objekts, einschließlich der Festlegung von Datenstruktur, den Funktionen und deren Implementierung wird als Klasse bezeichnet. So wie beispielsweise eine Variable vom Typ Integer eine Instanzierung dieses Integertyps darstellt, so ist auch ein Objekt eine Instanz eines bestimmten Klassentyps.
Funktionen in Objekten werden auch als Methoden bezeichnet. Sie verleihen dem Objekt bestimmte Verhaltensweisen und werden oft dazu benutzt, Zugriff auf die Daten im Objekt zu ermöglichen. Auf diese Weise können einerseits die Daten im Objekt vor äußeren Zugriffen geschützt werden und es existiert doch andererseits eine wohldefinierte Schnittstelle nach außen. Diese Zugriffskontrolle, welche eine Beschränkung des Zugriffs auf interne Details darstellt, ist ein wesentliches Merkmal objektorientierter Programmiersprachen und wird unter dem Begriff der Kapselung geführt.
|
In Objekten werden die Details implementiert. Sie liegen geschützt und versteckt im Inneren. Objekte besitzen eine Schnittstelle nach außen. Man unterscheidet äußere Sicht - Interface - und innere Sicht - Implementation. |
Wenn man Objekte und Klassen von innen betrachtet, wird man damit konfrontiert, wie sie zusammengestellt sind, wie sie arbeiten. Betrachtet man sie von außen, wie es ein Anwender tut, interessiert nur ihr Zweck und ihre Leistungsfähigkeit. Man klärt wofür sie da sind und was sie können. Die Kapselung von Variablen in Objekten wird häufig auch "Datenkapselung" und "Information-Hiding" genannt. Kapselung ist weitgehend auch bei der herkömmlichen, strukturierten Programmierung möglich, wird jedoch bei der objektorientierten Programmierung unter anderem durch die Einführung differenzierter Schutzbereiche besonders gut unterstützt.
|
---|
In den meisten Programmen wird zur Lösung eines bestimmten Problems nicht nur eins, sondern eine ganze Anzahl von Objekten existieren. |
Den Objekten werden bestimmte Verantwortlichkeiten zugewiesen, die sie durch ihre Funktionen erfüllen müssen. Durch Aufgabenverteilung und eine enge Zusammenarbeit wird der Auftrag des Systems ausgeführt. Neben dem Datenzugriff über die öffentlichen Methodenschnittstellen kommunizieren sie miteinander, indem sie Botschaften versenden und empfangen. So beschreibt es Dan Ingalls, einer der Entwickler der OO-Sprache Smalltalk, wie folgt: "Statt eines bitfressenden Prozessors, der Datenstrukturen hin- und herschaufelt, haben wir nun ein Universum von wohlerzogenen Objekten, die sich höflich gegenseitig bitten, zur Erfüllung ihrer jeweiligen Anliegen beizutragen." [1].
Methoden sind also ein Teil eines Objekts und "umlagern" dessen Daten. Allerdings gruppiert man bei der realen, technischen Umsetzung in Rechnern die Methoden nicht tatsächlich mit den Instanzvariablen eines jeden neuen Objekts. Solch ein Vorgehen würde objektorientierte Programme sehr vergrößern und Ressourcen verschwenden. Speicher wird deshalb nur für die Daten, die Variablen eines jeden Objekts, belegt. Es besteht kein Grund, Speicher für Methoden zu allozieren. Das Objekt braucht nur die Zugriffsmöglichkeit zu seinen Methoden, so daß alle Instanzen derselben Klasse auf denselben Funktionen-Pool zugreifen, ihn sich teilen können. Es gibt nur eine Kopie der Methoden im Speicher, egal wie viele Instanzen einer Klasse erzeugt werden.
Damit bei Funktionsaufrufen trotzdem eine Beziehung zwischen aufgerufener Methode und aufrufendem Objekt hergestellt werden kann, wird bei jedem Methodenaufruf ein impliziter Parameter an die aufgerufene Funktion übergeben. Dieser Parameter ist ein Zeiger auf die Objektinstanz. Aufgrund der großen Bedeutung dieses Zeigers wird ihm in objektorientierten Sprachen ein fester symbolischer Name zugewiesen. In der Sprache C++ nennt man ihn this und in Object Pascal self.
Objekte wurden so entworfen, daß sie in erster Linie als Datenbehälter dienen, weil man erkannt hat, daß Datenstrukturen, im Gegensatz zur Funktionsweise einer Anwendung, oft das einzig Verläßliche und Dauerhafte darstellen. Herkömmliche, nicht objektorientierte Programme, müssen bei Änderungen der Anforderungen oft komplett neu- bzw. große Teile umgeschrieben werden. Das zentrale Gerüst von Objekten in einer objektorientierten Anwendung, die Klassenstruktur, kann dagegen in solch einem Fall bestehen bleiben, wenn sie richtig und weitsichtig entworfen wurde. Objektorientierte Programme sind deswegen nicht nur flexibler, sondern auch noch wesentlich besser wartbar. Um einmal erstellte Software-Komponenten in demselben oder anderen Projekten erneut verwenden zu können, muß die Möglichkeit bestehen, die Dienste zu variieren, die ein Modul seinem Klienten zur Verfügung stellt. Diese, unter dem Begriff der Wiederverwendbarkeit bekannte, herausragende Eigenschaft objektorientierter Komponenten resultiert aus den Kennzeichen Kapselung, Vererbung, Polymorphismus, Überladen und dynamischen Eigenschaften.
Ein generelles Ziel objektorientierter Programmierung ist es, den Code so zu schreiben, daß er möglichst oft wiederverwendet werden kann. Die Wiederverwendbarkeit wird, ebenso wie bei strukturierter Programmierung, von mehreren Faktoren beeinflußt:
Durch Vererbung gibt ein Klasse seine Eigenschaften an eine neue Klasse weiter. Neue Klassen können auf Existierenden aufbauen, um bereits vorhandene Eigenschaften in modifizierter oder erweiterter Form zu übernehmen. Man erstellt zunächst weniger spezialisierte, elementare Grundtypen und erzeugt dann darauf aufbauend vererbte Klassen, die neben den grundlegenden noch zusätzliche, besondere Eigenschaften und Verhaltensweisen besitzen.
|
Beispiel einer Klassenhierarchie mit Superklasse Fahrzeug und den abstrakten Basisklassen Landfahrzeug und Wasserfahrzeug |
Vererbte oder auch abgeleitete Klassen können drei verschiedene Veränderungen erfahren:
Einmal vorhandene Methoden können von den Erben nie wieder entfernt werden. Auch im Basisobjekt vorhandene Variablen können von Nachfolgern nicht entfernt oder überschrieben (im Sinne einer Neu- oder Umdefinition) werden.
Durch Vererbung kann eine ganze Familie von Klassen entstehen, welche man Klassenhierarchie nennt.
In einigen objektorientierten Sprachen besteht daneben auch die Möglichkeit der Mehrfachvererbung. Ein Objekt erbt dabei nicht nur die Eigenschaften eines, sondern mehrerer Basisobjekte.
|
Objekt Amphibienfahrzeug entsteht durch Mehrfachvererbung aus Landfahrzeug und Wasserfahrzeug |
Durch den Vererbungsmechanismus müssen gemeinsame Eigenschaften nur einmal festgelegt werden. Vom "Code-Recycling" durch Vererbung verspricht man sich zum einen eine Produktivitätssteigerung bei der Softwareentwicklung, muß doch so nicht immer wieder "das Rad aufs neue erfunden" werden. Andererseits gelangt man zu einer erhöhten Zuverlässigkeit der Software, da weniger Code neu erstellt und getestet werden muß. Bereits als zuverlässig bekannter und getesteter Standard-Code aus umfangreichen Bibliotheken steht zur Verfügung.
Überladen und Polymorphismus stehen in engem Zusammenhang. Polymorphie entstammt dem Griechischen und steht für das Wort "Vielgestaltigkeit" bzw. die Möglichkeit, sich von mehreren Seiten zu zeigen. Operationen, die Werte beliebiger Typen übernehmen können, nennt man polymorph, während man unterschiedliche Operationen, die denselben Namen benutzen, überladen nennt.
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:
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].
|
Durchschnittlicher Zeitbedarf bei der Softwareerstellung [4] |
Negativ allerdings stehen den vielen Vorteilen und der großen Flexibilität objektorientierter Systeme ein prinzipiell erhöhter Ressourcen- und Rechenbedarf gegenüber. Ein System / Programm wird entsprechend [4] durch verschiedene Qualitätsmaßstäbe bewertet:
Korrektheit |
fordert exakte Erfüllung der Aufgabe |
Adaptierbarkeit |
Anpassung an ähnliche Probleme |
Portabilität |
Anpassung an andere Betriebssysteme |
Kompatibilität |
Kombinierbarkeit von Teilsystemen |
Zuverlässigkeit |
Wahrscheinlichkeit für befriedigende Ausführung |
Robustheit |
Verkraften von Fehlbedienung, u. ä. |
Verfügbarkeit |
Ausfall- bzw. Standzeiten |
Benutzerfreundlichkeit |
bewertet Schnittstelle Benutzer <=> Programm |
Wartbarkeit |
Fehlerbeseitigung und funktionale Erweiterung/ Anpassung |
Effizienz und Leistung |
bewertet Nutzung aller Betriebsmittel (wie Speicher und Rechenzeit) |
Da diese Forderungen teilweise im Widerspruch zueinander stehen und sich gegenseitig ausschließen, kann kein Programm alle Kriterien gleichzeitig, geschweige denn in idealer Weise erfüllen. Effizienz stellt also nur eine unter vielen Forderungen dar. Generell kann aber gesagt werden, daß der Einsatz objektorientierter Systeme die Erfüllung vieler der Kriterien begünstigt.
In vielen der heute verbreiteten objektorientierten Sprachen ist der eigentliche Compiler nur ein Teil des Entwicklungssystems. Er wird in einer integrierten Entwicklungsumgebung (IDE) von leistungsfähigen Editoren, ausgefeilten kontextsensitiven Hilfesystemen, einer Projektverwaltung, Klassenbrowsern, Debuggern, erweiterbaren Komponentenbibliotheken und weiteren Tools umgeben. Mehr und mehr gewinnt auch das "visuelle Programmieren" an Bedeutung. Die Bedienelemente einer zu erstellenden Anwendung werden vom Entwickler graphisch plaziert und angeordnet. Codefragmente können dann in einem weiteren Schritt den Bedienelementen und bestimmten, auswählbaren Ereignissen dieser Bedienelemente zugeordnet werden. Selbst Datenbankanbindungen- und verknüpfungen können interaktiv und auf visuelle Art erfolgen. Die benötigten Entwicklungszeiten lassen sich durch diese komfortablen Helfer ganz beträchtlich senken, während dessen die Fehlerrate sinkt. Der Entwickler wird von stupiden, immer gleichbleibenden Arbeitsschritten befreit und kann sich um so mehr auf die eigentliche Lösung einer bestimmten Aufgabe konzentrieren.
Alle genannten Vorteile OO-basierter Sprachen und ihrer Entwicklungssysteme erfüllen sich allerdings nicht von alleine, sondern nur dann, wenn der Phase der Softwareerstellung eine sorgfältige Analyse und ein wohlüberlegtes Klassendesign vorausgehen. Ziel der Analysephase (OOA) ist es, eine möglichst dauerhafte Klassenstruktur zu erstellen. Die Designphase (OOD) soll danach klären, wie das Programm selbst ablaufen soll und auf welche Weise die Aufgaben erfüllt werden. Man bemüht sich darum, die Klassenstruktur zu verfeinern, die Architektur des Programms zu erstellen, was auch konkrete Entscheidungen hinsichtlich Datenhaltung, Speicherverwaltung, Fehlerbehandlung u.s.w. beinhaltet, so daß dann anschließend eine reibungslose Implementierung erfolgen kann. Um dem Prozeß des Entwerfens objektorientierter Systeme eine klare Struktur zu geben, wurden mehrere Methoden entworfen, unter anderem die von G. Booch, dargestellt in [1]. Der grundsätzliche Ablauf in diesen beiden Phasen wird von ihm so dargestellt:
Booch teilt darüber hinaus den Entwurfsprozeß in Mikroprozesse und den Makroprozeß (entsprechend 1. bis 4.) ein. Mikroprozesse betreffen die tägliche Arbeit des Entwicklers und schließen das Finden von Klassen und Objekten, ihrer Attribute, Methoden und Beziehungen untereinander ein. Das Entwurfsverfahren läuft im Kern so ab: Zuerst werden sehr abstrakte Klassen des Anwendungsbereichs gesucht, die anschließend im Mikroprozeß bearbeitet werden. Dabei entdeckt man Klassen auf anderen Abstraktionsniveaus, wie Oberklassen. Einige Klassen werden sich als unnötig erweisen und werden somit wieder verworfen. Jede der neuen Klassen wird wieder in den Mikroprozeß eingeschleust und man hangelt sich so mit jeder neuen Runde des Mikroprozesses auf eine niedrigere Abstraktionsstufe herunter. Das Verfahren wird durch eine Reihe, in enger Beziehung zu einander stehender Diagramme unterstützt: Klassen-, Zustands-, Objekt-, Interaktions-, Modul- und Prozeßdiagramme. Es existiert eine stattliche Anzahl von Programmen, die bei der Analyse und dem Design objektorientierter Systeme behilflich sind und den Entwickler unterstützen.
Im letzten Schritt des Makroprozesses wird das gewonnene Objektmodell in eine Programmiersprache umgesetzt, die natürlich objektorientiertes Programmieren erlauben muß, besser jedoch aktiv fördern sollte. Neben Sprachen wie Simula und Smalltalk, die das Erstellen eleganten OO-Codes ermöglichen, wurden im Laufe der Zeit sehr vielen Sprachen, die zunächst nur die prozedurale Strukturierung und Modularisierung zuließen, objektorientierte Spracherweiterungen hinzugefügt. Typische Vertreter sind die Sprachen C und Pascal. Sie besitzen unter anderem Recordtypen und Zeiger und beherrschen beschränkte Formen der Typerweiterung, sowie der Kapselung. Während bei Sprachen wie PL/1, Fortran, Cobol und Ada mit ihren objektorientierten Erweiterungen eine nicht-triviale Umsetzung bestehenden Codes von der jeweiligen Vorgängersprache notwendig ist, besitzt C++ die Sprache C und Object Pascal die Sprache Pascal als praktisch vollständig implementierte Teilsprachen. C++ und Object Pascal fanden sicher auch wegen der leichten Wiederverwendbarkeit bestehenden Codes Akzeptanz in der Industrie. Aus diesem Grund sollen im folgenden diese beiden Sprachen und ihre derzeitige Umsetzung in zwei kommerziell vertriebenen Entwicklungsumgebungen miteinander verglichen werden.
Die Sprache C++ wurde Anfang der 80er Jahre maßgeblich von Bjarne Stroustrup entwickelt [6]. Sein Wunsch war es, eine Programmiersprache zu schaffen, die das objektorientierte System der Sprache SIMULA mit dem sehr leistungsfähigen Compiler C verbindet und das "Konzept der Klassen" effektiv umsetzt. So entstand zunächst eine Spracherweiterung, die Stroustrup "C mit Klassen" nannte. Diese wurde in den folgenden Jahren durch ihn mit dem Ziel erweitert, die Sprache einem möglichst großen Kreis von Programmierern nahezubringen. Sie wurde in der ersten Zeit zunächst noch als Präprozessor in C realisiert und bekam bald den Namen C++. Um dem Ziel einer großen Verbreitung nahe zu kommen, wurde besonders darauf Wert gelegt, daß diese neue Sprache abwärtskompatibel zum bisherigen C sein sollte. Der neue, elementare Sprachkonstrukt "class" ist eine Erweiterung des C-Schlüsselwortes "struct" und war somit den C Programmierern vertraut. So sagt Stroustrup: "Mit dem Entwurf von C++ wollte ich ein Werkzeug zur Lösung von Problemen schaffen und nicht eine bestimmte Behauptung beweisen; die anschließende Entwicklung dieser Sprache war auf die Bedürfnisse der Programmierer ausgerichtet." [6]
Eine allgemeingültige Sprachdefinition wurde durch ihn im Buch "The C++ Programming Language" gegeben und wird mittlerweile durch ein internationales Komitee standardisiert (ANSI / ISO) und beständig weiter entwickelt. Die derzeit aktuell gültige Version trägt die Nummer 3.0. Eine Vielzahl bestehender C++ Compiler halten sich, ebenso wie Visual C++ der Firma Microsoft, relativ streng an diese Vorgaben, bieten darüber hinaus aber noch zusätzliche Erweiterungen an.
PASCAL wurde 1970 durch Prof. Niklaus Wirth mit dem Ziel entwickelt, eine kleine Lehrsprache zu Unterrichtszwecken zu erhalten, anhand derer gute Programmiertechniken demonstriert werden konnten. Der Name Pascal wurde zu Ehren des französischen Mathematikers und Philosophen Blaise Pascal (1623 - 1662) gewählt. Pascal zeichnet sich durch starke Typbindung und eine Reihe vorgegebener Typen aus, bietet aber auch die Möglichkeit, benutzerdefinierte Typen zu erstellen. Auch diese Sprache fand viele Anhänger und verbreitete sich insbesondere deswegen rasch, weil bald für alle gängigen Computersysteme Compiler zu Verfügung standen.
Auch Standard-Pascal wurde vor einiger Zeit normiert, bekannt unter dem Namen ISO-Pascal. 1989 wurde eine erweiterte Normierung unter dem Namen "Extended Pascal" veröffentlicht (ISO 10206). Man hat seit dem jedoch versäumt, Anpassungen vorzunehmen, so daß bis heute standardisierte Vorgaben zu objektorientierten Erweiterungen fehlen. Einzig ein unverbindlicher Bericht unter dem Namen "Technical Report on Object-Oriented Extensions to Pascal" wurde bisher veröffentlicht. [8]
Trotzdem hat sich Pascal ständig weiter entwickelt und besitzt heute ebenfalls objektorientierte Spracherweiterungen. Erweiterungen haben die Firmen vorgenommen, die kommerziell Compiler für Pascal entwickelt haben. Dabei hat sich der Softwarehersteller Borland hervorgetan, der in Pascal frühzeitig objektorientierte Erweiterungen implementierte. Der ihrer aktuellen Entwicklungsumgebung "Delphi" zugrunde liegenden Sprache haben sie den Namen "Object Pascal" verliehen.
C++ und Object Pascal besitzen sehr viele Gemeinsamkeiten. Neben den nicht zu übersehenden Unterschieden im Sprachumfang finden sich aber auch häufig Unterschiede im Detail, die zunächst leicht übersehen werden können. Deswegen soll im folgenden der Sprachumfang beider Systeme detailliert betrachtet und verglichen werden. Alle Angaben zu C++ beziehen sich auf das Entwicklungssystem "Microsoft Visual C++ Version 4.00 Professionell Edition" für INTEL-basierte Systeme. Ausführungen zu Object Pascal beziehen sich auf die konkrete Realisierung in Borlands Compiler "Delphi Version 2.0 Client/Server". Beide Systeme laufen nur auf Windows 32 basierenden Betriebssystemen und können auch nur für diese Betriebssysteme Maschinencode erzeugen.
Einen ersten Eindruck von der Komplexität der beiden Sprachen bietet folgende Tabelle (erweitert nach [5]):
Sprache |
Schlüsselworte |
Anweisungen |
Operatoren |
Seiten Dokum. |
Pascal |
35 |
9 |
16 |
28 |
Modula-2 |
40 |
10 |
19 |
25 |
Object Pascal (Delphi v2.0) |
92 |
24 |
23 |
198 |
C |
29 |
13 |
44 |
40 |
C++ v1.0 |
42 |
14 |
47 |
66 |
C++ v3.0 |
48 |
14 |
52 |
155 |
Visual C++ v4.0 |
83 |
22 |
61 |
291 |
Ada |
63 |
17 |
21 |
241 |
Schlüsselworte (Keywords) haben in einer Programmiersprache eine feste Bedeutung und können nicht umdefiniert werden. Beispiele sind: class, if, for, goto und register.
Anweisungen (Statements) beschreiben algorithmische Aktionen, die ein Programm ausführen kann. Man unterscheidet zwischen einfachen Anweisungen, wie z. B. Zuweisungsanweisung (:=), Prozeduranweisung, Sprunganweisungen und strukturierten Anweisungen. Zu ihnen zählen z. B. Blockanweisungen, Schleifen und bedingte Anweisungen.
Streng betrachtet besitzt Object Pascal nur 67 Schlüsselworte. 25 weitere Worte nennt Borland "Standard-Anweisungen" mit vordefinierter Bedeutung [9]. Zu ihnen zählen Begriffe wie assembler, message und virtual. Ein Neudefinieren dieser Wörter ist theoretisch möglich, wovon aber strikt abgeraten wird. Man muß diese Standard-Anweisungen deswegen als Quasi-Schlüsselworte ansehen.
Das bloße Zählen der Anzahl der Schlüsselwörter, Anweisungen und Operatoren kann leicht ein verzerrtes Bild von der Komplexität verschiedener Sprachen liefern. So weist C++ einige Schlüsselwörter auf, die trotz gleichen Namens je nach Anwendungsbereich eine komplett andere Bedeutung haben. Als ein extremes Beispiel kann hier das Wort "static" angeführt werden. Es gibt erstens die lokale static Variable, die ihren Wert über das Blockende hinaus behält. Es existieren zweitens mit static definierte dateibezogene Bezeichner, deren Gültigkeit / Sichtbarkeit auf diese Datei begrenzt sind. Es gibt drittens Klassenvariable, die static sind und deren Existenz dadurch unabhängig von der Klasse ist. Und es gibt viertens static Member- (Klassen-)Funktionen. Hier steht der static-Bezeichner dafür, daß diesen Funktionen der "this"-Zeiger nicht als Argument übergeben wird. Die Existenz von Schlüsselkonzepten mit Mehrfachbedeutungen führt leicht zu Verwirrungen. In der oben aufgeführten Tabelle kommen solche komplexen Sachverhalte nicht zum Ausdruck.
Trotzdem macht allein die Anzahl der fest vordefinierten Schlüsselworte, Standard-Anweisungen und Operatoren deutlich, daß C++ und Object Pascal im Vergleich zu ihren prozeduralen Vorfahren durch die objektorientierten Erweiterungen wesentlich komplexer und umfangreicher geworden sind. Sie reflektieren offensichtlich die Tatsache, daß viele Veränderungen nötig waren, um den neuen Anforderungen gerecht zu werden. Sie zeigen aber auch, daß das Erlernen und Meistern dieser neuen Sprachen schwieriger geworden ist. Erschwerend kommt beim objektorientierten Programmieren gegenüber dem in C und Pascal hinzu, daß mindestens ein extra Schritt beim Entwurf des OO-Designs nötig wird, bevor mit dem eigentlichen Schreiben der Software begonnen werden kann.
Programme bestehen aus Elementen, die man Tokens nennt, und stellen eine Sammlung von Zeichen des Compiler-Vokabulars dar. Sie schließen in beiden Sprachen die Zeichen des einfachen (7 Bit) ASCII-Zeichensatzes ein und lassen keine deutschen Umlaute zu. Eine Trennung der Tokens wird durch eingefügte "Whitespaces" wie Leerzeichen, Tabulatoren, Zeilenumbrüche und Kommentare definiert. Bei der lexikalischen Analyse produziert der Compiler interne Tokens, indem er jeweils die längste Zeichenkette auswählt, die einem Token entspricht. Es gibt fünf Token-Kategorien :
- Schlüsselworte (reservierte Wörter / Keywords)
- Bezeichner (Identifiers)
- Konstanten (inklusive String-Konstanten)
- Operatoren
- Trennzeichen (Punctuators)
Bezeichner werden zur Kennzeichnung von Objekten, Variablen, Klassen, Strukturen, Funktionen, Prozeduren, Labels und Makros verwendet. Namen von Bezeichnern bilden eine Folge von Buchstaben, Ziffern und dem Unterstrichzeichen "_". Bezeichner dürfen nicht mit einer Ziffer beginnen und keine Leerzeichen enthalten. VC++ verwendet maximal 247 Zeichen eines Bezeichners, während in Object Pascal nur die ersten 63 Zeichen signifikant sind. C++ unterscheidet zwischen Groß- und Kleinschreibung von Bezeichnern, ebenso bei Schlüsselwörtern. Es ist aber auch beim Schreiben von Pascal-Programmen empfehlenswert, wiederholt auftretende Bezeichner in gleicher Weise zu schreiben. Die Lesbarkeit wird verbessert und die Wiedererkennung erleichtert.
Kommentare werden beim Übersetzungsvorgang nicht ausgewertet, sondern einfach ignoriert. C++ und Object Pascal leiten einzeilige Kommentare durch die Zeichen // ein. Sie reichen immer bis zum Ende der Zeile. Mehrzeilige Kommentare werden in C++ durch /* eingeleitet und mit */ beendet und in Object Pascal mit { oder (* eingeleitet und entsprechend mit } bzw. *) beendet.
C++ |
Object Pascal |
//einzeiliger C++ Kommentar |
//einzeiliger Pascal Kommentar |
/* das ist ein mehrzeiliger Kommentar in C++ */ |
{das ist ein mehrzeiliger Kommentar in Pascal} (* das ebenso *) |
Innerhalb von Kommentaren dürfen alle Zeichen des erweiterten ASCII-Zeichensatzes verwendet werden. Die einzige Ausnahme betrifft Object Pascal und verbietet die Verwendung des Zeichens $ bei mehrzeiligen Kommentaren. Tokens der Form {$...} werden als Compiler-Befehl interpretiert. C++ benutzt einen sogenannten Präprozessor, um derartige Compiler-Befehle noch vor der eigentlichen lexikalischen Analyse auszuwerten. Dieser konvertiert den Quellcode von seiner Präprozessor-Form in reine C++ Syntax um. Solche Direktiven werden hier immer durch das Symbol # eingeleitet.
Bedingte Übersetzung beherrschen beide Compiler. Als gleichwertig kann betrachtet werden:
|
VC++ |
Delphi |
Bedingtes Symbol mit dem angegebenen Namen definieren und das Symbol auf TRUE setzen. Bedingte Symbole gleichen booleschen Konstanten, da sie entweder den Wert TRUE oder FALSE besitzen. |
#define identifier |
{$DEFINE identifier} |
Definition eines zuvor definierten bedingten Symbols identifier aufheben. |
#undef identifier |
{$UNDEF identifier} |
Der darauf folgende Quelltext wird nur dann übersetzt, wenn die angegebene Bedingung zutrifft (TRUE liefert), also identifier bei ifdef definiert bzw. bei ifndef nicht definiert ist. |
#ifdef identifier #if defined identifier #ifndef identifier #if !defined identifier |
{$IFDEF identifier} {$IFDEF identifier} {$IFNDEF identifier} {$IFNDEF identifier} |
Steuern den Kontrollfluß bzw. setzen das Ende der bedingten Anweisungen. |
#else #elif #endif |
{$ELSE} keine Entsprechung {$ENDIF} |
VC++ |
Delphi |
Bsp.: #if !defined( EXAMPLE_H ) #define EXAMPLE_H class Example { ... }; #endif |
Bsp.: {$IFDEF _DEBUG} {ShowMessage('Debug'+StrText)} {$ELSE} {ShowMessage(StrText)} {$ENDIF} |
Einige Symbole werden durch die Compiler bzw. Bibliotheken bereits vorbelegt, wie z. B. _WIN32 in VC++ und Win32 in Object Pascal. Sie erleichtern das Erstellen von portierbarem Code. Neben den einfachen Mechanismen zur bedingten Compilierung existieren in C++ weitere Möglichkeiten, vor dem eigentlichen Übersetzungsvorgang Manipulationen am Quelltext vorzunehmen.
Der Inhalt einer ganzen Datei kann in C++ durch die Präprozessor-Anweisung #include Datei, in Pascal durch die Compiler-Anweisung {$I Datei} oder {$INCLUDE Datei} im Quelltext eingefügt werden. Das Einfügen erfolgt an der Stelle, an der die Compileranweisung auftritt. In C++ wird die include-Anweisung intensiv dazu benutzt, um die, in getrennten Dateien geführten, Schnittstellendefinitionen (Header-Dateien) und Implementierungen (cpp-Dateien) wieder zusammen zuführen. Weitere Erläuterungen folgen im Abschnitt "Programmstruktur".
Beide Compiler können Projekteinstellungen, global bzw. lokal auf einen bestimmten Text-abschnitt bezogen, im Quelltext umdefinieren. C++ bemüht dazu wiederum seinen Präprozessor und verwendet sogenannte "Pragma - Direktiven" als Compiler-Anweisungen in der Form #pragma CompilerInstruction. Sie stellen maschinenspezifische Anweisungen dar. Delphi nutzt statt dessen wieder seine Art der Compiler-Anweisungen in der Form {$...}. Um beim Übersetzen die Ausgabe von Warnungen zu vermeiden / die Optimierung zeitweise auszuschalten, könnte folgendes geschrieben werden:
VC++ |
Delphi |
// Warnung Nr. 34 wird // unterdrueckt #pragma warning(disable: 34) void func() { a; } #pragma warning(default: 34) |
// alle Warnungen werden // unterdrueckt {$WARNINGS OFF} procedure func; begin a; end; {$WARNINGS ON} |
// jegliche Optimierung aus #pragma optimize("", off) void func() { b; } #pragma optimize("", on) |
// jegliche Optimierung aus {$OPTIMIZATION OFF} procedure func; begin b; end; {$OPTIMIZATION ON} |
Pragma-Anweisungen sind, ebenso wie die Anweisungen zum bedingten Compilieren, auf Grund der Präprozessor-Nutzung unter C++ wesentlich flexibler einsetzbar, als dies mit den Compileranweisungen von Delphi der Fall ist. Der Einsatz des Präprozessors ermöglicht überdies noch die Definition von Makros; eine Spracherweiterung, die Delphi fehlt (zu Makros mit Parametern siehe auch Abschnitt "2.3.5 Programmstruktur").
Operator |
VC++ |
Object Pascal |
kleiner als |
|
|
kleiner gleich |
|
|
größer als |
|
|
größer gleich |
|
|
enthalten in |
|
|
Ungleich- heit |
|
|
Gleichheit |
|
|
Zuweisungs- operator |
|
|
Anmerkung: |
Der Zuweisungsoperator und der Operator zur Prüfung auf Gleichheit wurden bereits in der Sprache C vielfach kritisiert. Allzuleicht wird statt einer gewünschten Gleichheits-prüfung unbeabsichtigt eine Zuweisung durchgeführt: void main() { int a = 3; // a ist 3 if (a = 4) printf("a ist 4"); else printf("a nicht 4"); } Ausgabe: a ist 4 Der else-Zweig wird nie durchlaufen werden. Bei if (a = 4) wird nicht a geprüft, sondern a wird der Wert 4 zugewiesen und der Erfolg dieser Zuweisung geprüft. Der verläuft natürlich immer erfolgreich und liefert also TRUE. Der Compiler kann solch einen Fehler nicht aufdecken, weil es kein syntaktischer oder semantischer, sondern ein logischer Fehler ist. |
|
Erweiterte Zu- weisungs- operatoren |
sofern keine Seiteneffekte auftreten, wie z.B. beiv[i++] *= 5; |
Statt dessen können die, sowieso besser lesbaren, normalen Operatoren angewendet werden. |
|
int a, b; a += b; a -= b; a *= b; a /= b; a += b; a %= b; a >>= b; a <<= b; a &= b; a ^= b; a |= b; |
var a, b: Integer; a := a + b; a := a - b; a := a * b; a := a / b; a := a + b; a := a mod b; a := a shr b; a := a shl b; a := a and b; a := a xor b; a := a or b; |
Addition |
|
|
Subtraktion |
|
|
Multiplikation |
|
|
Division |
|
|
Ganzzahl- Division |
Alternativ: implizite Typkonvertierung, die aber fehleranfälliger ist: i = 10 / 3; |
Alternativ: explizite Typkonvertierung: i:= Trunc(10 / 3); |
Modulo- operator |
|
|
boolscher NICHT Operator |
|
|
boolscher UND Operator |
|
|
boolscher ODER Operator |
|
|
bitweises 1-er Komple- ment |
|
|
bitweises Schieben nach links (shift left) |
|
|
bitweises Schieben nach rechts (shift right) |
|
|
bitweiser UND Operator |
|
|
bitweiser ODER Operator |
|
|
bitweiser EXKLUSIV- ODER Operator |
|
|
Vektor- operator |
|
|
Funktions- aufruf |
|
|
Bereichs- zugriffs- (Scope-) Operator |
|
|
Inkrement- operator |
|
|
Dekrement- operator |
|
|
Anmerkung: |
Die C++ Ausdrücke, die gleichzeitig eine Wertzuweisung und eine Inkrementierung / Dekrementierung ihres Wertes ausführen, sind nicht exakt zu dem angegebenen Pascal-Code äquivalent. |
Die C++ Ausdrücke ermitteln ihren rechtsseitigen Ausdruck nur einmal. Bei komplizierten Ausdrücken mit Seiteneffekten können deswegen beide Formen unterschiedliche Ergebnisse liefern. |
SizeOf- Operator |
|
|
Punkt- operator |
|
|
Pfeil- operator |
|
|
Dereferen- zierungs- operator |
|
|
Anmerkung: |
* ist Präfix-Operator. |
^ ist Postfix-Operator. |
Adreß- operator
|
|
|
Referenz |
|
|
Anmerkung: |
|
Das Wort Referenz wird auch in der Dokumentation zu Object Pascal verwendet, steht hier aber als Synonym für Zeiger (Objektreferenz) und Typ-referenz für Klassen (Klassenreferenz). |
New - Operator |
für einfache Typen |
für einfache Typen |
New - Operator |
für Vektor (Array) Typen |
für Vektor (Array) Typen GetMem(var P: Pointer, Size: Integer) var str_dyn: PChar; GetMem(str_dyn, 20); oder alternativ mit "New": type PMyStr20 = ^MyStr20; MyStr20 = Array[0..19] of Char; ··· var str_dyn: PMyStr20; ··· New(str_dyn); |
Anmerkung: |
Der new Operator wird in C++ auch dazu verwendet, dynamische Objekte anzulegen. |
In Object Pascal dagegen werden dynamische Objekte ausschließlich mit dem Constructor Create instanziert! |
Delete- Operator |
für einfache Typen |
für einfache Typen |
Delete- Operator |
für Vektor (Array) Typen |
für Vektor (Array) Typen FreeMem(var P: Pointer, [Size: Integer]) FreeMem(str_dyn, 20); |
Anmerkung: |
Der Scope-Operator :: muß benutzt werden, wenn der new / delete- Operator überladen wurde und der globale new / delete Operator aufgerufen werden soll. |
|
Konditionaler Operator |
|
Gleichwertiger Ersatz ist durch Nutzung des if / else Ausdrucks möglich. if (a > b) then z:= a else z:= b; |
Komma- operator |
Der Gesamt-Ausdruck wird von links nach rechts ausgewertet, und der Wert des gesamten Ausdrucks entspricht dem Wert von AusdruckN. int a, b, c; a = 0; b = 0; c = (a++, b++, b++, b++); // a = 1, b = 3, c= 2 |
Einen gleichwertigen Ersatz erhält man durch das sequentielle Aufrufen der N Ausdrücke. var a, b, c: Integer; a:= 0; b:= 0; inc(a); inc(b); inc(b); c:= b; inc(b); // a = 1, b = 3, c= 2 |
Klassen- element- zeiger |
.* (bei statischen Objekten) ->* (bei dynamischen Objekten) class Test{ public: int i; }; void main() { // Klassenzeiger für // Klasse Test int Test :: *DatZeiger; // soll auf i zeigen. // Ist in allen Ob- // jekten der Klasse // Test nutzbar. DatZeiger = &Test :: i; // statisches Objekt a // erzeugen Test a; // dynamisches Objekt b // erzeugen Test* b = new Test; // dynamisches Objekt c // erzeugen Test* c = new Test; // Datenbelegung a.i = 11; b->i = 26; c->i = 45; printf("a.i = %i", a.*DatZeiger); printf("b->i = %i", b->*DatZeiger); printf("c->i = %i", c->*DatZeiger); } Ausgabe: a.i = 11 b->i = 26 c->i = 45 |
Klassenelementzeiger auf Methoden erfolgt durch Methodenzeiger-Typ und den Punktoperator. Siehe dazu Beispiel Methodenzeiger im Abschnitt "2.3.2 Standardtypen". |
Anmerkung: |
Klassenelementzeiger (class member pointer) können nicht nur auf Klassen-Daten, sondern auch auf Klassen- Methoden zeigen. |
|
Objekt-Typ- Informations- Operator |
typeid() liefert als Ergebnis eine Klasse "type_info", die die Run-Time-Type-Informationen (RTTI) enthält. #include <typeinfo.h> class Test{ // leere Klasse }; void main() { Test* a = new Test; printf("Klasse heißt %s", typeid(a).name()); } Bildschirm-Ausgabe: Klasse heißt class Test * |
weil alle Objekte in Object Pascal immer alle Typ-Informations-Methoden besitzen. type Test = class // leere Klasse end; var a: Test; begin a:= Test.Create; writeln('Klasse heißt ', a.ClassName); end. Bildschirm-Ausgabe: Klasse heißt Test |
dynamische Objekt- Typ- prüfung |
|
|
dynamische Objekt- Typ- konver- tierung (zur Lauf- zeit) |
|
|
statische Typ- konver- tierung
(zur Über- setzungszeit) |
Anmerkung: Statt des Cast-Operators () sollten die neueren Operatoren static_cast, reinterpret_ cast und const_cast verwendet werden. [6, Seite 429] |
Anmerkung: Der Cast-Operator () in Object Pascal entspricht in seiner Wirkungsweise dem Opera-tor static_cast in C++. |
statische Typ- konver- tierung
(zur Über- setzungszeit) |
|
|
statische Typkonver- tierung
(zur Über- setzungszeit) |
|
Operatoren, die "reinterpret_cast" und "const_cast" entsprechen würden, sind in Object Pascal nicht definiert, da deren Wirkungsweise dem typensicheren Konzept von Pascal diametral entgegen stehen. Um trotzdem nicht zu unflexibel zu werden, definiert Object Pascal den Typ Variant. Variablen dieses Typs können ein Wert darstellen, der seinen Typ dynamisch während der Laufzeit ändern kann. |
In beiden Sprachen besitzen Funktionsaufrufe nach Scope- und Vektoroperator die höchste Priorität. Um logisch falsche Ausdrücke zu vermeiden, sollten logisch zusammengehörende Ausdrücke in Klammern () zusammengefaßt werden.
C++ gestattet das sogenannte Überladen von Operatoren innerhalb von Klassen. Eine Erläuterung folgt im Abschnitt "2.3.6 Klassen und Objekte".