Dr. Michael Peltzer, Berater bei der IBM Unternehmensberatung GmbH, Hamburg
Objektorientierung (OO) wird zur Zeit als der Deckel gehandelt, der auf alle Töpfe paßt. Kaum ein Produkt, dem in der Reklame nicht dieses Etikett als unabweisbares Gütesiegel angeheftet wird. Kaum ein Problem, das durch die Anwendung von OO nicht schon so gut wie gelöst wäre.
Das geht so weit, daß ein OO-Guru behauptet: "Meine Katze ist objektorientiert." Damit müßte es dem letzten klargeworden sein: Objektorientierung ist die natürlichste Sache der Weit - Bio-Programmierung gewissermaßen. Wer möchte da noch abseits stehen und weiterhin unnatürlich strukturiert programmieren? Doch nur verbohrte Prozeduren-Opas!
Ein echter deutscher Professor erzählt gerne die Geschichte von einem Restaurantbesuch. Objektorientiert, funktioniert alles bestens: Man geht hin, bestellt und ißt. Prozedural hingegen gibt es nur Probleme: Der Gast muß erst einmal alle Zutaten selbst besorgen, sie dann ins Restaurant mitbringen und mit der Bestellung dem Koch übergeben, damit der sie nach Wunsch zubereitet. Dann endlich kann er essen wie gehabt. Irgendwie blöd, nicht? Es spricht also alles für OO, schon im Alltag.
Wer jetzt fragt, ob Programme Mäuse jagen sollen oder ob künftig beim Nachrichtenaustausch zwischen Objekten keine Parameter (informationstechnisch für "Zutaten") mehr übergeben werden, der liegt ganz verkehrt. Die unpassenden Vergleiche wie der mit dem Restaurant sollen nicht aufklären, sondern sie dienen dazu, Begeisterung für Objektorientierung zu wecken und möglichst vergessen zu machen, daß es sich um ein Informatikkonzept handelt und nicht um den Stein der Weisen. Über das Konzept sagen sie überhaupt nichts, sie machen nur klar, daß einige kluge Leute von der geistigen Trägheit ihrer Kollegen Informationsverarbeiter so überzeugt sind, daß sie es mit sachlichen Argumenten gar nicht erst versuchen, und statt dessen ihre Opfer mit allerlei Pseudo-Anschaulichkeiten zu ködern trachten.
Nicht besser ist die scheinwissenschaftliche Tour. Da wollte mir einmal ein Marketing-Orakel weismachen, daß OO mächtig viel mit Algebra zu tun hätte. So versuchen Leute, für die der "Satz von Sylvester" mit "Prosit" endet, mit der Aura der Mathematik Stimmung zu machen für Sachverhalte der Informatik, die sie selbst nicht verstanden haben.
Dabei taugt das Paradigma der Objektorientierung wirklich etwas. Sein allgemeiner Inhalt ist schnell angegeben, auch wenn die Zahl der Definitionen inzwischen Legion ist. Grundsätzlich geht es um Einkapselung, Abstraktion und Vererbung. "Einkapselung" bedeutet, daß die aufgrund der Von-Neumann-Architektur unserer Computer getrennt gedachten Elemente jeder Informationsverarbeitung - Daten und Verarbeitungslogik - als Einheit, als Objekt, aufgefaßt werden. "Abstraktion" meint, daß Objekte konkrete Exemplare einer abstrakt definierten Klasse sind. "Vererbung" schließlich bezeichnet die Möglichkeit, Hierarchien von Klassen so zu bilden, daß bei der Definition einer Subklasse alle Merkmale der Oberklasse(n), also Datenstrukturen und die in sogenannten Methoden niedergelegte Verarbeitungslogik, übernommen werden.
Diese und andere OO-Prinzipien (Information Hiding, Dynamic Binding etc.), stammen ursprünglich aus der Entwicklung von Programmiersprachen und nicht aus Biologie oder Philosophie. Sie resultieren weder aus dem aufmerksamen Vergleich von Call-Return-Konstruktionen mit einem Gasthausbesuch noch aus der Analyse zyklischer Körper. An diesem Ort haben sie eine handfeste Bedeutung und dort sind sie weit über ihr ursprüngliches Einsatzsgebiet hinaus von Bedeutung.
Die Hauptziele, die man mit objektorientierter Programmierung (OOP) erreichen will, sind eine bessere Wiederverwendbarkeit des einmal geschriebenen Codes, daraus folgend kürzere Entwicklungszeiten und leichtere Wartung. Diese Vorteile der OOP sind, wenn sie wirklich genutzt werden, von unschätzbarem Wert. Gratis sind sie nicht. Bezahlt werden sie vor allein mit einem größeren Ressourcenverbrauch und einer relativ schlechten Performance. Große Probleme bereitet auch noch die Verwaltung der Klassenbibliotheken - das Finden von Codestücken sollte nicht länger dauern als ihre Neuentwicklung. Und natürlich hat OOP das Standardleiden der DV, das heißt, es fehlen Standards. Die Folge ist eine mangelnde Kompatibilität der angebotenen Programmiersysteme. Nicht zu unterschätzen ist schließlich die Unvertrautheit der meisten Programmierer mit OOP-Dialekten.
Bei den Datenbanken spielt OO ebenfalls eine große Rolle, aber gerade nicht als Merkmal der nächsten Generation! Relationale Datenbanken eignen sich nämlich sehr gut, wenn es um satzförmige Daten geht, wie sie im kommerziellen Betrieb üblich sind. Daß die meisten Daten jedoch weder in relationalen noch in hierarchischen oder Codasyl-DBs gespeichert sind, liegt mit daran, daß sie dort nicht gut hineinpassen: Die beispielsweise bei CAD-Anwendungen benutzten Datenstrukturen sind derart komplex, daß sie sich nur sehr aufwendig in Tabelleneinträge zerlegen lassen. Entsprechend langsam wäre der Zugriff. Genau für solche Bereiche - CAD, CASE, Büroautomatisierung mit Ton und Bild - bieten sich OODBs an: In ihnen lassen sich komplexe Strukturen ohne weitere Zerlegung direkt speichern.
Es wird auch viel über OO-Analyse und OO-Design gesprochen, und in gewisser Hinsicht macht es auch Sinn, die Prinzipien der Objektorientierung hier anzuwenden. Dem Analytiker helfen sie, sauber zu trennen zwischen dem zu lösenden Problem in der realen Welt und den Möglichkeiten einer Programmiersprache für Von-Neumann-Architekturen. Beim Design unterstützen sie die Modularisierung. Alles zusammengenommen ist die Objektorientierung also eine äußerst vielversprechende Entwicklung. Fazit: Viel Lärm um etwas sehr Brauchbares. Aber viel zuviel Lärm!
Dieser Artikel ist bereits in der Nr. 6/92 der EDV-Aspekte, Seite 14, der COMPUTERWOCHE Verlag GmbH, München, erschienen.