Wer auf dem PC objektorien- tierte Anwendungen erstellen will, hat die Qual der Wahl: Verheissen Hybridsprachen wie C++ leichte Erlernbarkeit und geringen Ressourcen-Verbrauch, so locken die "reinen" OO-Sprachen mit kurzen Entwicklungszeiten und mit Portabilitaet. Goetz Hofmann* und Andreas Mohnberg* zerpfluecken den Mythos von der problemlosen Migration.
Die objektorientierte Programmierung gilt als die Antwort auf viele Probleme in der Software-Entwicklung. Die gesteigerte Leistungsfaehigkeit der PC-Hardware und die Verfuegbarkeit von entsprechenden Softwaresystemen fuer die objektorientierte Entwicklung machen auch den PC als Plattform fuer diese Technik interessant - insbesondere als Client innerhalb einer Server- Client-Architektur.
Auf welchem Weg welche objektorientierte Technologie einzufuehren sei, ist eine Frage, die in letzter Zeit die Kassen der Anbieter von entsprechenden Tagungen und Seminaren fuellt. Im Vordergrund steht die durchaus begruendete Angst, nach der aufwendigen Einfuehrung - mit Schulungen, Investitionen in die Anschaffung von Entwicklungs- umgebungen und Hardware sowie den zu erwartenden Leistungseinbruechen der Entwickler - am Ende mit leeren Haenden dazustehen.
Zwei Schritte sind notwendig
Die Einfuehrung objektorientierter Technologie besteht aus zwei wesentlichen Schritten: Zum einen muss das, was das Wesen dieser Technologie ausmacht, vermittelt werden. Dazu gehoert es, die Entwickler mit einschlaegigen Begriffen wie Objekt, Klasse, Methode und Vererbung vertraut zu machen und ihnen den Umgang mit den zugehoerigen Konzepten nahezubringen. Im zweiten Schritt muessen die Mitarbeiter lernen, diese Konzepte umzusetzen, weil schliesslich aus einem objektorientierten Design auch "nur" ein Stueck Software werden soll.
Grundsaetzlich kann ein objektorientiertes Design in (fast) jeder Programmiersprache umgesetzt werden. Aber genauso wie heute kaum noch jemand auf die Idee kaeme, ein Haus ausschliesslich mit Axt und Schaufel zu bauen, werden auch Software-Entwickler versuchen, moeglichst geeignete Umsetzungswerkzeuge zu benutzen. In diesem Fall ist damit eine entsprechende Entwicklungsum- gebung gemeint.
Der Kern jeder objektorien- tierten Entwicklungsumgebung besteht - genau wie bei einer konventionellen Umgebung - aus einer Programmiersprache, die dazu dient, ein Problem in eine dem Rechner adaequate Darstellung umzusetzen. Die Programmiersprachen, die objekt- orientierte Arbeitsweisen unterstuetzen, lassen sich in zwei Klassen einteilen, einerseits in die speziell fuer diese Technologie geschaffenen Sprachen, andererseits in die Weiterentwicklungen bereits bekannter Programmiersprachen, auch hybride Sprachen genannt. Die jeweils prominentesten Mitglieder dieser beiden Klassen sind zum einen Smalltalk, das seit Ende der 60er Jahre verfuegbar ist, aber auch die rein objektorientierte Sprache Eiffel, zum anderen C++ und Objective C als Weiterentwicklungen von C sowie weitere Hybridsprachen auf der Basis von Pascal. Die Weiterentwicklung von Programmiersprachen fuegen zumeist den vorhandenen Sprachelementen neue Konstrukte zur Beschreibung von Klassen und Instanzen hinzu. Die in der Regel vorhandenen Konstruktionen fuer Funktions- und Prozeduraufrufe werden in Nachrichten umgemuenzt.
Wichtig ist bei all diesen Systemen, dass die Aufwaertskompatibilitaet gewahrt bleibt. Ein C++-Compiler muss demnach in der Lage sein, auch C-Programme zu uebersetzen - eine Ruecksichtnahme, die bei neu entwickelten Systemen nicht noetig ist.
Welche Strategie ist nun die richtige? Anbieter von Weiterentwicklungen bekannter Systeme, behaupten gern, dass die Einarbeitungszeit in die neue Technologie durch das Zurueckgreifen auf Bekanntes verkuerzt werden kann.
Der Schritt von der "traditionellen" Programmierung mit ihrer strikten Trennung von Daten und Funktionen hin zu der objektorientierten Technik mit ihrer integralen Ansicht von Daten und Methoden erfordert jedoch ein radikales Umdenken in den Koepfen von Entwicklern. Die Moeglichkeit, sich bei Problemen mit der neuen Denkweise in die alte Technologie "retten" zu koennen, birgt die Gefahr, dass die Einfuehrung der neuen Technik eher verzoegert als beschleunigt wird. Nicht vergessen werden sollte dabei der Zeit- und Erfolgsdruck, unter dem Software-Entwickler notorisch stehen.
Bibliotheken beschleunigen den Entwicklungsprozess
Es gibt zwar die fundamentale Erkenntnis, dass sich in jeder Programmiersprache Fortran-Programme schreiben lassen ("Real Programmers don+t use Pascal"); es gibt aber Sprachen, die es einem leichter machen als andere. Und zu diesen Sprachen gehoert nun einmal C.
Es gibt aber noch einen weiteren Punkt, der den scheinbaren Vorteil der hybriden Sprachen relativiert: Wer eine traditionelle Programmiersprache erlernt, muss am meisten Zeit und Energie dafuer aufwenden, die Syntax der Programmiersprache selbst zu lernen. Die Umgebung der Programmiersprache, also die mitgelieferten Bibliotheken, sind bei den klassischen Systemen in der Regel recht klein. Ausserdem kommt der Entwickler normalerweise mit einem minimalen Satz dieser Funktionen oder Prozeduren aus - zum Beispiel fuer Ein- und Ausgabe.
Objektorientierte Entwicklungssysteme (wir verlassen jetzt den Bereich der reinen Programmiersprachen) leben hingegen von den umfangreichen Klassenbibliotheken, die mit der "nackten" Sprache mitgeliefert werden. Gerade die Kenntnis und Verwendung der Bibliotheken fuehrt zu der Entwicklungsbeschleunigung, die die Einfuehrung objektorientierter Techniken so verfuehrerisch macht. Der zweifelsohne grosse Aufwand dafuer, sich in diese Bibliotheken einzuarbeiten, relativiert natuerlich den Gewinn, der durch eine leichtere Erlernbarkeit der reinen Programmiersprache erworben wird.
Neben den lernpsychologischen Nachteilen der Hybridsprachen, gibt es jedoch ein weiteres gravierendes Problem: Das Laufzeitverhalten objektorientierter Programme ist dadurch gekennzeichnet, dass in schneller Folge Objekte entstehen und auch wieder geloescht werden. Deshalb muss die Speicher- verwaltung in hohem Masse dynamisch sein.
Hybride Programmiersprachen ueberlassen diese Aktionen dem Entwickler. Dabei ist es zwar zumeist einfach zu bestimmen, wann ein Objekt erzeugt werden muss. Hingegen schafft die Entscheidung, wann ein Objekt geloescht werden kann, in der Regel Probleme. Man denke zum Beispiel an ein Objekt "Kunde", das an verschiedenen Orten - beispielsweise im Vertrieb sowie in der Buchhaltung - Referenzen besitzt. Natuerlich sollte der Kunde erst geloescht werden, wenn er alle Rechnungen bezahlt hat. Dieses Problem ist unter dem Stichwort "referentielle Integritaet" anzusprechen.
Es gibt aber bei den hybriden Programmiersprachen noch ein viel banaleres Problem: Die Freigabe der Speicherbereiche muss naemlich explizit durch den Aufruf der entsprechenden Funktionen durchgefuehrt werden. Das ist nicht nur laestig, sondern erfordert - vor allem bei komplex aufgebauten Objekten - unter Umstaenden auch einiges Nachdenken. Im Falle eines Fehlers treten die merkwuerdistgen Effekte auf, die daraus entstehen, dass Pointer ploetzlich auf etwas nicht mehr Sinnvolles zeigen.
Die echten objektorientierten Programmiersprachen haben dieses Problem durch die "Garbage Collection" wesentlich eleganter geloest. Dabei entscheidet das System eigenstaendig, wann ein Objekt nicht mehr gebraucht wird, und gibt den Speicherplatz frei. Wir wollen nicht verschweigen, dass diese Technik auch Nachteile bringt. Komfort kostet Leistung; das ist nicht nur bei der Automatikschaltung eines Autos so, sondern auch im Bereich der Software. Fuer Anwendungen, bei denen es auf hoechste Effizienz ankommt, haben also die hybriden Sprachen durchaus ihre Existenzberechtigung. Wenn aber schnelle Entwicklungszeiten im Vordergrund stehen (zum Beispiel beim Rapid Prototyping), haben die Sprachen mit Garbage Collection auf jeden Fall die besseren Karten.
Ein zunehmend wichtigeres Aufgabengebiet fuer PCs ist ihre Rolle als Client in einer Netzumgebung. Dabei werden Anwendungen lokal auf dem Client ausgefuehrt, die zentralen Datenbanken und Dateisysteme liegen auf einem oder mehreren Servern im Netz. Die Neuentwicklung von Applikationen fuer diese Umgebungen bieten die Chance, neue Technologien fuer die Umsetzung zu verwenden - nach heutigem Verstaendnis in der Regel objektorientierte Methoden.
Die Vorgehensweise bei dieser Neuentwicklung laesst sich wiederum in verschiedene Technologien einteilen: zum einen in reine PC- Applikationen, die ueber Bibliotheken mit der zentralen Datenhaltung kommunizieren, sowie zum anderen in objekt- orientierte Anwendungen, die so aufgebaut sind, dass die Objekte auf jedem Knoten im Netz - unabhaengig von Hardware und Betriebssystem - lauffaehig sind ("Portable Objects").
Die letztgenannte Technologie bietet die interessante Moeglichkeit, Applikationen fuer verschiedene Plattformen aus einem Guss zu gestalten. Die Probleme, die daraus erwachsen, dass Objekte innerhalb der Anwendung auf Objekte in der Datenbank - sei sie nun objektorientiert oder relational - abgebildet werden muessen, entfallen dabei. Leider sind noch nicht viele dieser Systeme verfuegbar. Es gibt allerdings durchaus Produkte, in denen dieser Ansatz konsequent verfolgt worden ist.
Objektorientierte Technologien fuer den PC sind auf dem Vormarsch, und das mit gutem Grund. Die ehemalige Rolle von Pascal als ideale Lehrsprache in der strukturierten Programmierung kann in der objekt- orientierten Anwendungsent- wicklung sicher das konzeptionell sehr saubere Smalltalk uebernehmen. C++ und andere hybride Sprachen haben ihre Vorteile hingegen, wo es auf eine Effizienz ankommt, die auch durch eine zu erwartende Leistungssteigerung der Hardware nicht aufzufangen ist.
In einem professionellen Umfeld sind vor allem Tools interessant, die das Arbeiten in typischen "Downsizing"-Umgebungen mit heterogenen Netzen und PCs als Clients unterstuetzen. Dazu gehoeren an vorderster Front Systeme, die Portable Objects unterstuetzen. Fuer die Zukunft ist in dieser Hinsicht jedoch ein gewichtiger Impuls von der Implementierung des Corba-Standards auf PC- basierten Systemen zu erwarten.
* Dr. Goetz Hofmann leitet das Competence Center der PBS GmbH in Kiel; Andreas Mohnberg ist zustaendig fuer den Bereich Applikationsentwicklung.