Objektorientiert lautet die Verheißung dieser Tage. Keine Woche vergeht, ohne daß irgendwo eine Konferenz zu diesem Thema stattfindet oder ein Artikel darüber erscheint. Trotz allen Rummels: Das Ganze ist mehr als nur ein Trend. Man verspricht sich außergewöhnliche Vorteile von dieser neuen Weise der Systementwicklung. Die ständig wachsende Komplexität der Anwendungen, verbunden mit Forderungen nach immer kürzeren Entwicklungszeiten bei gleichzeitiger Steigerung der Qualität läßt traditionelle Methoden des Software-Engineerings an Grenzen stoßen. Diese Schallmauer soll nun mit Hilfe der objektorientierten Programmierung durchbrochen werden. Wiederverwendbarkeit ist das Zauberwort.
Der Weg in das gelobte Land des mehrfach verwendbaren Codes ist jedoch nicht frei von Stolpersteinen. Dieser Artikel sagt Ihnen deshalb nicht nur, welche Vorteile Sie aus dem neuen Ansatz ziehen können, sondern auch, mit welchen Schwierigkeiten Sie zu rechnen haben - und wie Sie die Sache angehen sollten, damit sie trotzdem klappt.
Selbst wenn die Schwerpunkte mehr auf dem Wie und Wann liegen als auf dem Was oder Warum, ist eine kleine Einführung in das Thema unvermeidlich.
Die Grundlage der Objekt-Technologie
Das objektorientierte Paradigma lebt weitgehend von folgenden Abstraktionen:
- Kapselung ist die Zusammenfassung einer Datenstruktur mit den für diese Struktur definierten Operationen (Methoden) zu einer logischen Einheit! Eine gute Kapselung unterstützt Information Hiding und Implementation Hiding. Ersteres reduziert die externe Sichtbarkeit der Daten auf die vom Entwickler festgelegten Schnittstellen. Letzteres macht den Benutzer unabhängig vom physischen Innenleben des Objekts.
- Abstrakte Datentypen sind das Ergebnis einer guten Kapselung - also Struktur plus Methoden in einem. Natürlich wird ein Magnetband mit Kundenstammdaten auch in Zukunft nur Daten (und keinen Programmcode) speichern. Eine objektorientierte Datenbank hingegen wird unter anderem Code für benutzerdefinierte Zugriffsmethoden enthalten und somit die Anwendungen entlasten.
- Objektivierung und Klassifizierung zerlegt ein System in Objekte. Objekte mit gleicher Struktur und gleichem Interface werden in Klassen zusammengefaßt. Die Klasse ist gewissermaßen eine Fabrik, die zur Laufzelt immer neue, gleichartige Objekte erzeugt
- Vererbung und Polymorphie: Die Idee ist einleuchtend. Besteht Bedarf für eine neue Objektklasse, deren Struktur und Interface nur eine Erweiterung einer bestehenden Klasse darstellt, so wird die neue Klasse von der alten abgeleitet Struktur und Methoden werden dabei vererbt. So können wir zum Beispiel die Klasse "Mitarbeiter" von einer Basisklasse "Person" ableiten.
Im Idealfall besteht ein System aus Objekten, die vordefinierte Zustände einnehmen und Nachrichten austauschen. Die Polymorphie ist es, die uns erlaubt, Nachrichten an Objekte zu senden, von denen lediglich eine Basisklasse bekannt ist. Die Nachricht wird abhängig von der abgeleiteten Klasse unterschiedlich interpretiert.
Die wichtigste (und am meisten propagierte) Eigenschaft objektorientierter Software ist deren Wiederverwendbarkeit, also die Steigerung der Produktivität. Wunschziel ist die Konstruktion neuer Anwendungen aus vorhandenen Bausteinen einer Klassenbibliothek bei minimalem Aufwand für die Entwicklung neuer Klassen. Höhere Produktivität verkürzt die Entwicklungszeit und verbessert Ihre Wettbewerbschancen.
Die Verwendung fertiger und bewährter Bausteine anstatt umfangreicher Neuentwicklungen verringert das Risiko von Inkompatibilitäten und Programmierfehlern erheblich und verbessert damit die Produktqualität. Dies nicht nur deshalb, weil weniger kodiert werden muß, sondern auch weil sich mit einer wachsenden Zahl vorhandener Objektklassen das Prototyping erheblich beschleunigen läßt.
Objekte werden wie Makros eingesetzt
Auch steht Objektorientierung für die Fähigkeit, größere und leistungsfähigere Systeme zu bauen. Die klassische strukturierte Analyse nach de Marco verwendet eine funktionale beziehungsweise ereignisorientierte Zerlegung eines Systems. Dies führt zu einer (für diese Vorgehensweise typischen) Aufspaltung von Daten- und Prozeßmodellierung. Der objektorientierte Ansatz überwindet diese Spaltung und verbessert die Möglichkeiten der Partitionierung großer Systeme.
Die Anzahl der Codezeilen ist (neben anderen Größen) ein Faktor für die Komplexität eines Programmes. Die in einer Klassenbibliothek abgelegten Methoden enthalten durchschnittlich 30 bis 50 Anweisungen einer Hochsprache. Der Aufruf einer Methode wirkt also wie ein Makrobefehl, der die Leistung einer Codezeile vervielfacht, ohne die Komplexität des Codes zu erhöhen.
Soweit also die guten Nachrichten. Doch jede Münze hat zwei Seiten. Hier nun die schlechte Nachricht: Programmiersprachen und Werkzeuge, die die objektorientierte Philosophie schon heute perfekt unterstützen, können und sollten wir nicht erwarten. Im Gegenteil: Der Wunsch nach Kompatibilität zu vorhandenen Betriebssystemen und Subsystemen, wie Netzwerken oder grafischen Oberflächen, führt eher zu einer Bevorzugung hybrider Programmiersprachen wie zum Beispiel C+ + . Und es wird noch einige Zeit dauern, bis wir hier eine Stabilisierung erwarten dürfen. Die Gründe hierfür sind:
Zunächst einmal werden wichtige Grundkonzepte wie Parallelität und Nachrichten austausch (Message Passing) bislang so gut wie gar nicht unterstützt. Daran ändern auch TASK-Konzepte oder der Aufruf von Funktionen mit "umgedrehter" Syntax nichts. Sie müssen nur einmal einen Smalltalk-Programmierer fragen, wie er eine Meldung gleichzeitig an alle Objekte im System schickt (Broadcasting), ohne einen Wust von Hilfskonstruktionen zu bemühen. Dabei gilt Smalltalk vielen als "das objektorientierte Sprachsystem" überhaupt. Denken sie daran, daß gerade an Parallelrechner-Konzepten und Client-Server-Architekturen intensiv gearbeitet wird. Beides unterstützt grundlegende Forderungen des objektorientierten Ansatzes und wird einen großen Einfluß auf diesen Bereich ausüben.
Sprachen wie Smalltalk oder Eiffel unterstützen den objektorientierten Ansatz zwar besser als hybride Sprachen, gewähren dem Programmierer jedoch wenig Kontrolle über die Struktur elementarer Datentypen und deren Ablage im Speicher. Dem Benutzer eines abstrakten Types kann das egal sein - den Entwickler einer Objektklasse für einen Geräte- oder Netzwerktreiber stellt dieses vor große Probleme.
In hybriden Sprachen wiederum fehlen zum Teil elementare Sprachkonstrukte wie zum Beispiel Exception-handling (Behandlung von Ausnahme- beziehungsweise Fehlersituationen). Auch bei den Werkzeugen für die Programmierung sieht es trübe aus. CASE-Tools sind teilweise erst in Ansätzen vorhanden.
"Wir benötigen kein Analysetraining - wir sind objektorientiert", so lautet die Meinung mancher "Spezialisten" auf diesem Gebiet. Wer einmal beobachtet hat, wie schnell mit Smalltalk ein Prototyp zusammengestrickt werden kann, mag so denken. Aber Vorsicht: Die Entwicklung einer sauberen hierarchischen Klassenbibliothek verlangt sorgfältigstes Vorgehen. Welche Klassen werden überhaupt benötigt? Und können diese als Basis für zukünftige Klassen dienen? Sind die Klassen, die für eine bestimmte Domäne entwickelt wurden, auch wirklich in der ganzen Division einsetzbar?
Ohne detaillierte Analyse, die das Umfeld viel stärker bewertet als bisher, ist der Aufbau einer solchen Bibliothek nicht möglich.
Wiederverwendbarer Code muß irgendwo gespeichert werden, am besten in einer Bibliothek. Diese ist zentral zu verwalten - kein leichtes Unterfangen für weltweit operierende Unternehmen mit ihren dezentralen Entwicklungsabteilungen. Erstklassige Werkzeuge zum Durchsuchen der Bibliothek nach geeigneten Klassen sind notwendig, damit Mehrfachentwicklungen vermieden werden. Als "Bibliothekar" empfehle ich einen hartgesottenen Burschen (mindestens 1,90 Meter), der neue Klassen nur nach genauer Eignungsprüfung in die Bibliothek aufnimmt.
Der Aufbau einer solchen Bibliothek und die Bereitstellung der Werkzeuge kostet Sie zunächst einmal Geld. Richtlinien müssen entworfen und Personalentscheidungen getroffen werden. Gehen Sie davon aus, daß es mindestens ein Jahr (und ein bis zwei Pilotprojekte) dauert, ehe der erste wiederverwendbare Kode erzeugt wird. Betrachten Sie das bis dahin ausgegebene Geld als Investition - in Ihr Unternehmen und Ihre Mitarbeiter. Und glauben Sie niemandem, der Ihnen einen schnellen Ertrag verspricht. Was Sie jetzt tun sollten? Ganz einfach: Versuchen Sie mitzuwachsen. Warten Sie nicht ab, bis perfekt ausgereifte Sprachen und Tools zur Verfügung stehen. Diese sind erfahrungsgemäß komplex und erschweren Ihren Mitarbeitern den Einstieg. Definieren Sie ein bis zwei Pilotprojekte (am besten in unterschiedlichen Betriebssystem-Umgebungen), und geben Sie Ihren Mitarbeitern die Chance, sich an das objektorientierte Denken zu gewöhnen. Beobachten Sie kritisch den Markt für objektorientierte Datenbanken und CASE-Tools. Halten Sie Ausschau nach Standardbibliotheken mit einem Sortiment von Basisklassen. Investieren Sie in die Ausbildung Ihrer Mitarbeiter. Dann ist das verheißene objektorientierte Paradies nicht mehr weit.