Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.


23.08.1991

Objektorientierung ist keine Philosophie

Der in der Informationsverarbeitung so ungemein beliebte Ausdruck Philosophie ist dort eigentlich völlig fehl am Platze. Gemeint sind meist abstrakte Grundsätze, die eine Betrachtungsweise konstituieren - also Paradigmen.

In diesem Zusammenhang gewinnt Objektorientierung dadurch Konturen, daß sie vom prozeduralen Ansatz abgegrenzt wird. So bemerkt G. Booch, man könne aus den Verben einer Programmspezifikation auf die Prozeduren und aus den Substantiven auf die Objekte schließen (What is and isn't object-oriented design, in: American Programmer, 1989). Daten (Objekte) und die Weisen ihrer Verarbeitung (Prozeduren) gehören jedoch zusammen, das heißt, sie machen voneinander getrennt keinen Sinn. Es kommt ja auch niemand auf die Idee, in Fragen der Satzkonstruktion einen "major shift" vom Tu-Wort-Approach zum Ding-Wort-Ansatz zu vollziehen!

Gern wird die OO-Philosophie auch am Kontrast von Diagrammen verdeutlicht. Hausbacken, antiquiert etc. ist dann eine "functional decomposition":

Daß das nichts taugt, bemerkt der Kenner gleich an den starren Kästen und geraden Linien. Ganz anders hingegen OO:

- rund, modern, lebendig und irgendwie natürlicher. Auf dieser Ebene kann OO allerdings nicht mehr sein als ein Beitrag zur Pausen- und sonstigen Unterhaltung.

Das ist schade, denn das Paradigma der Objektorientierung kann sehr nützlich sein. Das leuchtet schnell ein, wenn man zum Beispiel an eine Verkehrsflußsimulation denkt. Die einzelnen Fahrzeuge stellen sich als relativ unabhängige und selbständig bewegende Einheiten dar, die aufeinander und auf gewisse Zeichen reagieren.

Das kann man sehr schön durch Module repräsentieren, in denen gewisse Daten (Geschwindigkeit, Ort, Richtung, Fahrzeugart) mit bestimmten Verarbeitungsweisen (Ändern, Anzeigen) zusammengeschlossen sind. Diese reagieren dann auf Nachrichten, die sie sich untereinander zusenden oder die sie von anderen Objekten (Ampel, Polizist, etc.) zugesandt bekommen.

In der Tat wurde OO nicht von modernen (Marketing-) Philosophen entworfen, sondern von Programmierern, die in den 60er Jahren Simulationsmodelle zu konstruieren hatten.

Aber auch der sogenannte prozedurale Ansatz hat eine gute Grundlage in der Analogie zu Arbeitsabläufen, die durch Anwendungssysteme unterstützt werden. Das Dekompositionsdiagramm kann einige Plausibilität für sich beanspruchen; es wurde nicht aus Rigidität oder Phantasielosigkeit erfunden.

Selbständige Elemente im fixierten Prozeß

Denkt man nämlich statt an Beziehungen selbständiger Elemente (Simulation) an einen fixierten Arbeitsprozeß mit definierten Zuständen und Varianten, dann paßt es sehr gut: Kunde A will eine Versicherung abschließen, eine Haftpflichtversicherung, als Lehrer, unter Einschluß des Fahrrads; B hingegen will seine auflösen.

Der Hierarchie der Bildschirmmasken im entsprechenden Programm kann durchaus einer notwendigen Folge der Arbeitsschritte entsprechen und die Menüauswahl spiegelt unter Umständen exakt die Varianten der Verarbeitung wider.

Auf dieser abstrakten Ebene, auf der die Philosophen beider Richtungen ihren Streit am liebsten führen, kann folglich überhaupt nicht ausgemacht werden, was das bessere Prinzip ist.