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.

16.08.1991 - 

Problemkreis und Lösungsweg müssen zusammenpassen

Das neue Paradigma ist mit Sicherheit kein Allheilmittel

Der Ansatz der Objektorientierung ist sehr interessant und bietet sich für bestimmte Problemkreise als Lösungsweg an. Aber der Versuch, jede Arbeit mit demselben Werkzeug zu erledigen, wird immer zu mittelmäßigen statt zu optimalen Ergebnissen führen. Diese Regel schließt, so Peter Mossack*, auch den Objektorientierungs-Ansatz ein.

Wenn wir einmal die Geschichte der Menschheit in bezug auf Modeströmungen betrachten, und diese mit der bisher noch jungen Geschichte der DV vergleichen, so können wir einige Parallelen feststellen. Ein Aspekt ist dabei die zyklische Wiederholung von Trends und Tendenzen.

Ein Beispiel dafür: Während die ersten CPUs nur über wenige Basisoperationen verfügten, entwickelten sich die Prozessoreinheiten zu immer komplexeren Systemen mit mehreren hundert Instruktionen. Dieser Trend hält zum Teil noch an; die CPU der ESA-370-Rechner von IBM hat zum Beispiel 420 verschiedene Instruktionen. Mit der Einführung der RISC-Maschinen (Reduced Instruction Set Computer) ist allerdings eine Rückkehr zu früheren Erkenntnissen zu beobachten.

Alles Neue wird für gut befunden

Das Kernelement einer solchen Mode heißt: Neuheit Neu ist entweder das, was es vorher noch nie gab, oder die Wiedererscheinung (sei es auch in abgewandelter Form) von dem, was es schon einmal gab - aber vor so langer Zeit, daß es bereits vergessen

wurde. Und das ist eines der Hauptkriterien für die Attraktivität von Produkten auch Softwareprodukten, in bezug auf ihre Vermarktung: "Was neu ist, ist gut", so lautet einer der Grundsätze für erfolgreiches Marketing.

Dieser Spruch mag trivial klingen, er reflektiert aber die tatsächliche Marktsituation im Softwarewerkzeug-Bereich. So wurden zum Beispiel Expertensystem-Werkzeuge in den letzten Jahren als revolutionäre neue Softwaretechnologie präsentiert, die

alle unsere Probleme lösen sollte. Jetzt befinden wir uns in der Ernüchterungsphase; man hat festgestellt, daß zumindest die "Werkzeuge der ersten Generation", nämlich die auf Produktionsregeln basierenden, nicht viel mehr als ein interessantes Spielzeug sind. Klar strukturierte und sauber implementierte Expertensysteme - sehr gut geeignet für bestimmte Problemklassen - erinnern uns hingegen an tabellarisch geschriebene Programme, eine fast uralte Erfindung.

Objektorientierung ist ein Paradigma. Es gibt eine Reihe von Eigenschaften, die sich im Laufe der Zeit als charakteristisch dafür herauskristallisiert haben. Dagegen existiert keine konkrete Theorie - wie es sie zum Beispiel für die funktionale Programmierung gibt - , auf der die Objektorientierung basiert.

Die Kernidee ist jedoch einfach zu erklären: In den klassischen Programmiersprachen hat man vorwiegend mit Programmen zu tun. Diese sind unterteilt in Sub- und Co-Routinen und werden meist von einem Hauptprogramm oder -system verwaltet. Dieses Hauptprogramm legt die Hauptsequenz der Verarbeitung fest. Zugleich werden hier die globalen Datenstrukturen definiert, auf die alle Unterprogramme zugreifen können und die das gesamte "Objekt" der Verarbeitung darstellen. Unterprogramme, die von anderen Unterprogrammen sowie von sich selbst Gebrauch machen, können wiederum ihre eigenen lokalen Datenstrukturen definieren.

Die dadurch beschriebenen Daten lassen sich somit nur innerhalb des Unterprogramms ansprechen. Sie sind also eingekapselt. Im Normalfall gehen solche lokalen Daten nach Verlassen des Unterprogrammes verloren. Bei manchen Programmiersprachen gibt

es jedoch die Möglichkeit, Co-Routinen zu definieren, bei denen dies nicht der Fall ist. Diese Co-Routinen verhalten sich im wesentlichen wie Hauptprogramme.

Das Thema der Kapselung von Daten durch Programmeinheiten ("Variable scoping") ist in der Literatur bereits umfangreich behandelt worden. Programmiersprachen wie zum Beispiel Pascal, Algol 68, Ada, Coral 66 und Modula 2 haben präzise, ausgeklügelte Definitionen und Algorithmen bezüglich "Variable scoping".

Während die konventionellen (strukturierten) Programmiersprachen als programmorientiert bezeichnet werden können, ist bei den objektorientierten Sprachen das Verhältnis zwischen dem Datenteil und dem Kontrollteil eines Programmes sozusagen umgekehrt; man beginnt mit den Datenstrukturen, oder besser gesagt: mit strukturierten Daten.

Um den Unterschied zwischen diesen "Structures" und den "Records" herkömmlicher Sprachen klar zu machen - und um die Vollkommenheit dieser neuen Strukturen zu betonen - , gab man diesen Struktureinheiten einen neuen Namen, sie heißen Objekte. Nicht die Programme enthalten ihre lokalen Datendefnitionen, sondern die Objekte besitzen jetzt lokale "Prozedurale Elemente", die nicht mehr Unterprogramme oder Sätze von Anweisungen heißen, sondern Methoden.

Der Mechanismus, mit dem die Kontrolle der CPU von einem Programm in ein anderes transferiert wird, ist bei herkömmlichen Sprachen der Programm- oder Unterprogramm-Aufruf. Der äquivalente Mechanismus bei den objektorientierten Sprachen heißt Nachricht. Als mögliche Fehlerbeschreibung eines in konventioneller Sprache programmierten Systems könnte man zum Beispiel sagen, ein Programm hätte ein anderes mit "falschen" Parametern aufgerufen. Bei einem in einer objektorientierten Sprache programmierten System würde man statt dessen sagen, ein bestimmtes Objekt hätte eine Nachricht "nicht verstanden". Neu ist vor allem die Vererbung

Tatsächlich neu an objektorientierten Programmiersprachen ist die Idee der Vererbung von Attributen und Methoden zwischen Objekten. Das ist ein Formalismus für die explizite Darstellung von Generalisierung und Spezialisierung sowie ein zugehöriger Mechanismus, um diese Vererbung von Eigenschaften programmtechnisch wirksam zu machen.

Eine Konsequenz der Vererbungsmechanismen ist, daß Objekte, die Objekten in unserer Welt entsprechen, auf eine sehr natürliche und somit intuitiv einsichtige Art und Weise strukturiert und manipuliert werden können. Man sagt, die Welt besteht aus Objekten, und diese Objekte haben Eigenschaften. Durch eine Analyse der Eigenschaften können die Objekte klassifiziert werden. Die Eigenschaften der Objekte sind nicht nur beschreibende Eigenschaften, sondern auch Verhaltenseigenschaften.

Für Prozeßsimulation hervorragend geeignet

Die Idee, eine Programmiersprache zu schaffen, die Formalismen enthält, mit denen man die Welt um uns herum möglichst komfortabel beschreiben und simulieren kann, ist zweifellos gut. Objektorientierte Programmiersprachen eignen sich zum Beispiel

hervorragend für Prozeßsimulation und als Werkzeuge für die Erstellung von grafik- und dialogintensiven Datenmanipulations-Anwendungen.

In puncto Korrektheit ist noch viel zu tun

Die Kunst besteht jedoch darin, das richtige Werkzeug für den Job zu nehmen. Niemand würde zum Beispiel auf die Idee kommen, ein Programm zur Lösung der Schrödinger-Gleichung für das Helium-Atom in einer objektorientierten Sprache zu erstellen, obwohl es sicher möglich wäre. Das Gleiche gilt für einen "Low-level"-Geräte- oder -Netzwerk-Treiber. Die Gründe hierfür liegen einmal bei der mangelnden Effizienz derart programmierter Systeme; zweitens sind objektorientierte Sprachen für solche Aufgaben semantisch zu hoch angesiedelt.

Ein anderer sehr wichtiger Aspekt, der leider allzuoft vernachlässigt wird, ist die Korrektheit, das heißt die beweisbare Fehlerfreiheit von Computersoftware. Stichworte hier sind Nichtprozeduralität (also deklaratives anstatt prozeduralem Programmieren), starke Typisierung und referenzielle Transparenz von Objekten. Unter diesem Aspekt ist seitens der Entwickler objektorientierter Sprachen noch sehr viel Arbeit zu leisten.

Abschließend bleibt zu sagen: Es wäre extrem blauäugig, den objektorientierten Ansatz als Allheilmittel zu verstehen. Es gibt nach wie vor keinen Ersatz für eine saubere Problemanalyse, gefolgt von einer kritischen Betrachtung der möglichen Lösungsansätze. Die Wahl eines Paradigmas und einer Programmiersprache kann nicht losgelöst von der Aufgabenstellung erfolgen; beide Teile müssen zusammenpassen.