Vorwort

Bis Mitte der 1960-er Jahre musste eine Firma, die die Dienste eines Rechners in Anspruch nehmen wollte, deutlich mehr Geld für die Hardware als für die Software ausgeben. Die Maschinen waren nicht leistungsfähig genug, um komplexe und umfangreiche Befehle durchzuführen. Das änderte sich in den 1970-er Jahren schlagartig. Zum einen stiegen die Kosten für das Testen der Software, zum anderen wurde es immer schwerer, Programmfehler zu finden oder die Software zu warten. Denn nach wie vor waren imperative Programmiersprachen das Maß aller Dinge. Wie in (die der Maschinensprache nächste Verwandte) Assembler, wurde einfach ein Befehl nach dem anderen aufgeschrieben. Dazu kamen jede Menge (bedingte) Sprungbefehle, so dass ab einigen tausend Zeilen Code eine Fehlersuche oder Optimierung nur mit größtem Aufwand möglich war. Dieser Sachverhalt wurde unter dem Namen Softwarekrise bekannt. Inzwischen hat sich viel zur Verbesserung der Situation getan, gelöst ist die Softwarekrise nach einhelliger Meinung der Fachwelt aber bis heute nicht.

Die Ursachen sind vielfältig. Ein Grund ist aber sicher, dass die Programmierer es damals nicht für erforderlich hielten, ihren Code so zu schreiben, dass er auch von anderen nachvollzogen werden konnte. Es darf bezweifelt werden, ob sie selbst nach einigen Jahren noch wussten, was genau mit den einzelnen Zeilen bezweckt wurde. Zu einer hohen Komplexität kam mangelnde Dokumentation hinzu. Aber auch der „Programmierstil“ selbst gab Grund zu Unzufriedenheit. Es fehlte an Standards und an brauchbaren Programmierparadigmen.

Vor der OOP hatte man versucht, die imperativen Sprachen durch bestimmte Vereinbarungen aufzuwerten. Die Paradigmen strukturierte Programmierung und/oder prozedurale Programmierung waren ein erster Versuch. Bei der strukturierten Programmierung musste man im Wesentlichen auf absolute Sprungbefehle verzichten. Realisiert wurde diese Technik zum Beispiel in der Sprache Pascal. Aber auch der prozedurale Ansatz konnte in Pascal verwirklicht werden: Das Aufteilen des Programms in kleine Teilaufgaben (Prozeduren). Beiden Konzepten gemeinsam ist die strikte Trennung zwischen Variablen und Prozeduren, ebenso leider auch die prinzipielle Möglichkeit einer Prozedur auf alle Variable zugreifen zu können und so eventuell eine unbeabsichtigte Änderung in einer Variablen auszulösen.

Ein weiterer Versuch, Ordnung in das „Programmier-Chaos“ zu bringen, war die Verwendung funktionaler Programmiersprachen, wie Haskell. Dort ist ein Programm eine mathematische Funktion. Eine Variable hat während der Ausführung immer den gleichen Wert. Die oben genannten Probleme bezüglich des Mangels an Kontrolle über eine Variable fallen somit weg. Der Nachteil: Der menschliche Verstand funktioniert nicht funktional und ist daher bei dieser Technik mitunter überfordert. Und so wundert es nicht, dass das funktionale Paradigma nur in wenigen Bereichen (Universität, Forschung) angewandt wird.

In der Praxis brachten weder die strukturierte noch die prozedurale Programmierung den gewünschten hundertprozentigen Erfolg. Etwas Neues musste erdacht werden. Bereits 1962 entwickelte Ole-Johan Dahl und Kristen Nygaard eine Programmiersprache namens Simula. Angeblich waren die beiden damit beschäftigt, ein Programm für eine Schiffssimulation zu schreiben. Das gestaltete sich wegen der vielen abhängigen Parameter derart schwierig, dass sie am Ende vollends den Überblick verloren. So sind sie angeblich auf die Idee gekommen, die Schiffe selbst als Objekte zu verwenden, die ihre Daten aber auch selbst verwalten. Auf diese Weise sollte eine möglichst genaue Modellierung realer Objekte möglich werden. Diese Objekte sollten untereinander nur mittels vorher festgelegter Schnittstellen (Interfaces) interagieren.

Eine solche Programmiersprache gab es bisher nicht, also musste sie neu geschaffen werden: So wurde Simula zum Prototyp aller objektorientierten Programmiersprachen. (Der Name OOP entstand allerdings erst später). Zu dieser Zeit war Pascal noch nicht einmal angedacht!

Etwas später formulierten Mitarbeiter der Forschungsabteilung der Firma Xerox erstmalig ein Klassenkonzept, das dann in der Programmiersprache Simula-67 realisiert und weiterentwickelt wurde. Klassen sind hier „Konstruktionsanweisungen“ für Objekte, wobei auch hier jedes Objekt eine überschaubare Menge an Variablen (hier Attribute genannt) und Prozeduren (hier Methoden genannt) enthält. In der Vorstellung der Entwickler ist ein Objekt eine Art „Lebewesen“, das auf „Nachrichten“ reagiert. Eine Reaktion kann in einer Antwort bestehen oder aber auch in der Änderung eines Attributs. Damit Wiederverwertbarkeit und Datensicherheit gewährleistet sind, müssen einige Regeln gelten, die im nächsten Kapitel dargestellt werden sollen.

Am besten kann man den Übergang vom prozeduralen zum objektorientierten Paradigma an der in den 70-er Jahren sehr beliebten Sprache C beobachten. Mitte der 80-er Jahre entstand aus C das heute, besonders bei den Jugendlichen, noch immer hoch angesehene C++. C++ ist nun nicht gerade ein Musterbeispiel der OOP. Dennoch kann man damit nach OOP-Vorgaben programmieren! Dass die prozedurale Methode dort auch noch erlaubt ist, wird ja nur von den Puristen verachtet!

Heute sind die wichtigsten objektorientierten Programmiersprachen Java, Delphi und C#. Man kann wohl sagen, dass die Industrie durch die fortschreitende Komplexität der Anwendungen, ohne den objektorientierten Ansatz noch lange nicht auf dem heutigen Stand wäre.

Zur Modellierung verwendet man hier die sprachenunabhängige UML (Unified Modeling Language). Mit Hilfe von Diagrammen wird hier die Abhängigkeit der Klassen mit ihren Strukturen dargestellt. In dem hier verwendeten JavaEditor ist ein UML-Tool integriert.

Dass OOP nicht auf ungeteilte Begeisterung stieß, versteht sich von selbst. So meinte Edsger Dijkstra, ein Wegbereiter der strukturierten Programmierung:

"Object-oriented programming is an exceptionally bad idea which could only have originated in California."

Man kann sich auch trefflich darüber streiten, ob OOP im Informatikunterricht der Oberstufe überhaupt behandelt werden soll. Einiges spricht tatsächlich dagegen:

• Gebraucht wird diese Technik erst bei Programmen mit vielen tausend Zeilen Programmcode. Solche Programme werden aber in der Schule kaum geschrieben.

• OOP ist keine eigenständige Theorie, wie etwa die Kryptologie, sondern lediglich eine Technik. Hier passt der Satz: OOP löst die Probleme, die wir ohne Computer nicht hätten! Professor U.Brandes (Universität Konstanz) formuliert es so: OOP ist ein Mittel zum Zweck. Nicht mehr, aber auch nicht weniger.

• OOP setzt voraus, dass die Realität durch Objekte modelliert werden kann (OOM: Objektorientierte Modellierung). Eine gewagte These, setzt sie doch voraus, dass Realität letztendlich durch eine Folge von Einsen und Nullen darstellbar ist.

• Viele noch heute häufig benutzte Programmiersprachen kommen völlig ohne OOP aus!

Die Gründe dafür:

• Zum Verständnis des objektorientierten Paradigmas werden viele Inhalte des dreijährigen Informatikunterrichts berührt.

• Die Modellierung realer Objekte durch OOP ist bei den in der Schule behandelten Beispielen verblüffend einfach und sorgt mit Hilfe der UML für schnelle erste Erfolge.

• Auch bei kleineren Programmen kann man den Vorteil der OOP gut nachvollziehen: Alles, was man irgendwann erarbeitet hat, kann problemlos in späteren Programmen weiterverwendet werden. Auch lassen sich Fehler leichter finden. Kurz formuliert: Nach kurzer Einarbeitungszeit wird die Arbeit des Programmierens deutlich vereinfacht.

 

 

Einführung: Herunterladen [odt][330 KB]

 

Weiter zu Sprachliches