fit 2002

Die Wurzeln objektorientierter Konzepte lassen sich bei genauerer Betrachtung bis in die frühen 40er und späten 50er des 19. Jahrhunderts zurückverfolgen, als frühe Arbeiten der AI bereits die Idee von ‚Objekten’ und ‚Objektattributen’ behandelten.

Ungeachtet dessen sehen viele die Einführung der Programmiersprache Simula ([Dahl und Nygaard, 1966]) als die Geburtsstunde des objektorientierten Paradigmas. Das Design und die Entwicklung von Simula entstand aus einem sozio-wissenschaftlichen Kontext:

Nachdem die Wissenschaft mathematische Modelle und die Simulation als Methoden zur experimentellen Erforschung von Phänomenen der realen Welt entdeckte und später die digitale Rechenmaschine Einzug hielt, gewann die Idee, Simulation könnte in allen computerunterstützten Disziplinen und Bereichen angewendet werden, immer mehr an Akzeptanz. Die Hoffnungen auf billigere und verlässlichere Simulationen und Experimente mussten anfänglich aufgrund der Unzulänglichkeit konventioneller Programmiersprachen wie bspw. Algol oder Fortran zu Grabe getragen werden. Die Norweger Dahl und Nygaard erkannten die Notwendigkeit einer Technologie, die in Natur und Simulationen vorkommenden Objekte und deren Wechselwirkungen zu formulieren. Nach mehreren Vorgängern wurde schließlich 1966 Simula67 vorgestellt, welches bereits Konzepte wie Klassen, Vererbung und Polymorphismus beherrschte.

Das folgende Jahrzehnt trug entscheidend zur Entwicklung objektorientierter Sprachen und graphischer Benutzeroberflächen wie wir sie heute kennen bei. In den späten 60er begann eine Periode politischer und sozialer Unruhe. Unter dem Einfluss des Vietnamkrieges wuchs die Unzufriedenheit der amerikanischen Bevölkerung. Viele Leute – besonders die junge Generation – strebte nach einer Neuverteilung der alten Machtstrukturen, gesellschaftlicher Re-Humanisierung und Forcierung von Bildung und Forschung. Die Kürzung von Forschungsgeldern für die Universitäten veranlasste viele Forscher und Studenten in die Wirtschaft zu wechseln. Unter ihnen war Alan Kay, der zur Firma Xerox wechselte. Beeinflusst durch die politische und soziale Situation und der Fähigkeit zur Vorausschau auf den zukünftigen Computermarkt verfolgte er eine Vision, namentlich ‚New Computing’.

Es war ein Weg, den vielen Problemen der amerikanischen Gesellschaft entgegenzuwirken. ‚New Computing’ würde jedermann Zugang zu einem Computer und damit den Zugang zu Informationen ermöglichen, Bildung und Forschung sowie Kunst und Kreativität durch Computerunterstützung forcieren. Unter diesen Vorstellungen formulierte eine Forschergruppe um Alan Kay bei Xerox in Palo Alto (Xerox Parc) das sogenannte ‚Dynabook’, welches ein Hard- und Softwaresystem spezifizierte. Der Hardwareteil wurde als Xerox Star, der Softwareteil als Smalltalk bekannt, wobei die erste Version von Smalltalk 1972 erschien. Bei der Entwicklung von Smalltalk wurde der Fokus auf den Benutzer konzentriert, sodass z.B. durch Grafiksupport und der Verwendung von objektorientierten Konzepten die Verwendung intuitiv und besonders auch für den Nicht-Fachmann verständlich war.

Bis heute wird Smalltalk bzw. seine ‚Dialekte’ (Smalltalk 80 und Smalltalk V) als die ‚klassische’ objektorientierte Sprache wegen seiner strikten Objektpolitik (alles wird als Objekt behandelt) angesehen. Zusätzlich zu den Eigenschaften anderer Sprachen beinhaltet Smalltalk auch eine Entwicklungsumgebung, welche wesentliche Auswirkungen auf die heute üblichen WIMP-Schnittstellen (WIMP – window, icon, mouse, pointer) hatte.

Die Einführung von Smalltalk trieb die Entwicklung weiterer objektorientierter Systeme voran, sodass zwischen 1980 und 1990 deren Anzahl regelrecht explodierte. Damals wurden viele Versuche unternommen, objektorientierte Programmiersprachen zu entwickeln, die die Möglichkeiten und Vorteile der objektorientierten Konzepte nutzten und die Nachteile wie Effizienzprobleme und die Nicht-Unterstützung von persistenten Objekten umgehen. Die aus dieser Zeit resultierenden Sprachen müssen in verschiedene Kategorien eingeteilt werden:

Objektorientierte Programmierung ersetzte allmählich traditionell strukturierte Programmier-techniken. Viele der bereits existierenden, konventionellen prozeduralen Programmier-sprachen wurden um objektorientierte Features erweitert. Die bedeutendsten Entwicklungen dieser Kategorie sind die Erweiterungen der Sprache C – Objective C und C++:

Objective C wurde 1984 von Brad Cox veröffentlicht und erweitert die Sprache C mit Smalltalkkonzepten durch eine zusätzliche Bibliothek. AT&T (Bjarne Stroustrop, 1983) entwickelte C++ durch Änderung des C Compilers und erweiterte die Syntax um einen neuen primitiven Datentyp für Klassen. Als Entwurfsziele standen Portabilität und Effizienz im Vordergrund. Andere Firmen haben sich dem Trend objektorientierter Programmierung angeschlossen und erweiterten ‚ihre’ Programmiersprachen dementsprechend (Visual Basic, Objective Pascal bzw. Delphi, Ada95, Modula3, Objective Cobol, CLOS etc.).

Eine der jüngsten objektorientierten Programmiersprachen wurde 1995 von Sun Microsystems vorgestellt – Java. Damals war Sun eine der führenden Hersteller von Unix-Workstations und wollte sein Geschäftsfeld um einige alternative Technologien, u.a. Consumer-Elektronik, erweitern. Ein Projekt namens ‚Green’ sollte den Einsatz von billigen, progammierbaren Mikroprozessoren in Consumer-Elektronikgeräten wie bspw. PDA’s, Haushaltsgeräten, interaktiven TV-Geräten etc. erforschen. Nachdem sich C++ für diese Zwecke als ungeeignet herausstellte, begann James Gosling mit der Entwicklung einer ursprünglich als ‚Oak’ bezeichneten Programmiersprache, die soweit wie möglich an C++ angelehnt wurde, um die Konzepte des weitverbreiteten C++ beizubehalten, ohne einige der darin enthaltenen, kaum verwendeten Features, wie bspw. Mehrfachvererbung weiterzuverwenden.

Nachdem Sun’s Consumer-Elektronik Initiative fehlschlug, wurde das Web durch Einführung von Netscape’s neuem Browser zur ‚Killer’–Technologie. Obwohl für einen anderen Zweck entwickelt, war Java wegen seiner Plattformunabhängigkeit, Sicherheit, Einfachheit und Robustheit für derartige Web-basierte Anwendung bestens geeignet und wurde neben C++ zu einer der populärsten objektorientierten Programmiersprachen.

Konzepte und Technik

Allgemeines

Im Gegensatz zu herkömmlichen prozeduralen Ansätzen wird in objektorientierten Programmiersprachen die logische Codeverteilung geändert. Anstatt Funktionen informal in verschiedene Dateien zu gruppieren wird die Funktionalität streng an den entsprechenden Typ gekoppelt.

Grundsätzlich gibt es viele Möglichkeiten Code zu strukturieren, wobei sich der objektorientierte Stil als sehr effizient herausstellt. Objektorientierte Technologie ist sowohl großartig als auch weitreichend. Ein sehr wichtiger Aspekt ist die implizite Trennung in Client- und Producerseite. Endbenutzer von Computersystemen und computerbasierenden Systemen erfahren den Einsatz objektorientierter Technologie in Form leichter bedienbarer Software (Anwendungen und Betriebssystemen) und flexibleren Services. Auf der anderen Seite sieht sich die Softwareindustrie mit sich dauernd ändernden Rahmenbedingungen konfrontiert. Die Notwendigkeit leicht erweiterbare bzw. änderbare Softwaresysteme zu entwickeln, hat das Interesse an neuen Konzepten und Techniken zur Systementwicklung – und design geweckt, wobei die Technik der Objektorientierung eine der vielversprechendsten Lösungen - besonders für skalierbare Anwendungen und Code-Wiederverwendung - darstellt.

Die Schlüsselkonzepte objektorientierter Technik beinhalten Klassen und Instanzen, Vererbung, Kapselung, Polymorphismus und Dynamisches Binden.

Klassen und Instanzen

Grundsätzlich versteht man unter einem Objekt physikalische und konzeptuelle Dinge, die in der Welt um uns anzutreffen sind, z.B. Software, Dokumente, Menschen, etc. Objekte besitzen zu jeder Zeit ihrer Existenz einen definierten Zustand, der den aktuellen Wert, die Situation oder die Verhältnisse des Objekts repräsentiert. Beispielsweise könnte der Zustand eines Bankkonto-Objekts die aktuelle Bilanz, der eines Uhr-Objekts die aktuelle Zeit, der eines Lichtquellen-Objekts ‚ein’ oder ‚aus’ sein. Für komplexere Objekte wie Menschen oder Autos können derartige Zustandsbeschreibungen sehr umfangreich sein.

Diese Darstellung der Welt wird in objektorientierten Programmiersprachen vollständig übertragen. Die Struktur von Objekten wird durch Attribute und das Verhalten durch Operationen (Methoden) definiert, wobei die Attribute den aktuellen Zustand des Objekts widerspiegeln.

Die Klasse für ein Fahrrad-Beispiel würde alle notwendigen Instanzvariablen wie den aktuellen Gang, Farbe, Anzahl der Gänge, etc. deklarieren, um ein allgemeines Fahrrad zu beschreiben. Ebenso würde sie alle Instanzmethoden enthalten, um das Fahrrad bedienen zu können, z.B. schalten, bremsen usw. Wird nun eine Instanz dieser Klasse erzeugt, alloziert das System genügend Speicher für das Objekt und seine Instanzvariablen. Jede Instanz erhält ihre eigene Kopie der in der Fahrrad-Klasse deklarierten Instanzvariablen.

Zusätzlich zu Instanzvariablen kann eine Klasse sogenannte Klassenvariablen und –methoden definieren. Eine Klassenvariable beinhaltet Information, die von allen Instanzen dieser Klasse gemeinsam genutzt wird, z.B. können alle von ‚Fahrrad’ instantiierten Objekte dieselbe Anzahl von Gängen haben. Klassenmethoden werden direkt in der Klasse, während Instanzmethoden in der eigenen Instanz aufgerufen werden.

Ein einzelnes Objekt ist im Allgemeinen nicht sehr hilfreich. Stattdessen erscheint ein Objekt normalerweise als Komponente eines größeren Programms, das viele andere Objekte enthält. Objekt-Interaktion ermöglicht höhere Funktionalität und Komplexität. Objekte interagieren und kommunizieren durch den Austausch von ‚Nachrichten’ untereinander, indem auf Methoden des Empfänger-Objekts zugegriffen wird. Das ‚Nachrichten’-Prinzip bietet u.a. zwei gravierende Vorteile:

§ Das (mögliche) Verhalten des Objekts wird ausschließlich durch seine deklarierten Methoden bestimmt, sodass der Nachrichtenaustausch alle Interaktionsmöglichkeiten zwischen Objekten abdeckt

§ Objekte müssen sich weder im selben Prozessraum, noch auf demselben Rechner befinden, um Nachrichten zu senden bzw. zu empfangen.

Vererbung

Grundsätzlich werden Objekte durch Klassen definiert. Objektorientierte Systeme gehen einen Schritt weiter, indem Klassen selbst durch andere Klassen definiert sein können. So können z.B. die Klassen ‚Mountainbikes’, ‚Rennräder’ oder ‚Tandems’ von der Klasse ‚Fahrräder’ abgeleitet werden, wobei die drei abgeleiteten Klassen als ‚Subklasse’ und ‚Fahrräder’ als Superklasse bezeichnet werden.

Jede Subklasse erbt die Struktur (Variablen und Methoden) von seiner Superklasse und kann zusätzlich eigene Variablen und Methoden deklarieren. Auf der anderen Seite kann von Subklassen eine geerbte Methode ‚überschrieben’ werden, um eine spezialisierte Implementierung dieser Methode anzubieten.

Vererbung kann in zwei Ausprägungen auftreten: Im Falle der einfachen Vererbung kann nur von einer einzigen Klasse abgeleitet werden, während einige objektorientierte Systeme auch das gleichzeitige Ableiten von mehreren Klassen (Mehrfach-Vererbung) zulassen.

Rambaugh beschreibt die Kapselung als die strikte Trennung externer, dem Benutzer zugänglicher Informationen von der internen Implementierung des Objektes, die dem Benutzer im Allgemeinen verborgen bleibt. Kapselung beschreibt also den Schutz der Interna eines Objekts vor direkter Manipulation durch Clients. Der Client wird auf das Senden von Nachrichten beschränkt, ohne Möglichkeit des direkten Zugriffs auf das Objekt, sodass der Zustand des Objekts nur durch die eigenen Methoden verändert werden kann.

Kapselung erlaubt Serviceanbietern die sichere Veröffentlichung seiner Services (Methoden) durch klar spezifizierte Interfaces. Durch das Prinzip von ‚Black Boxes’ muss der Benutzer keinerlei Wissen über den inneren Aufbau eines Services haben, sondern lediglich Zugang zu den vom Objekt durch Interfaces bereitgestellten Operationen.

Unter Polymorhismus versteht man die Fähigkeit eines Objekts zur Laufzeit auf verschiedene Instanzen einer Klasse zu referenzieren. Booch beschreibt Polymorphismus als ein Konzept der Typtheorie, in der ein Name, bspw. eine Variablendeklaration, sich auf Objekte mehrerer verschiedener Klassen mit gemeinsamen Vorfahr bezieht. Jedes durch diesen Namen bezeichnete Objekt kann auf verschiedene Weise eine Menge von Methoden nutzen.

Inklusions-Polymorphismus wird direkt durch das Prinzip der Vererbung implementiert, wodurch ein Objekt gleichzeitig mehreren Typen zugeordnet werden kann.

Methoden-Polymorphismus impliziert, dass Methoden mit demselben Namen auf verschiedene Objekte angewendet werden können. Es gibt zwei Formen von Methoden-Polymorphismus:

Dynamisches Binden ist die Fähigkeit, ein Objekt erst zur Laufzeit dynamisch an eine Operation zu binden. Mit anderen Worten verzögert dynamisches Binden die Zuordnung eines Funktionsaufrufs zum dazugehörigen Sourcecode bis zur Ausführungszeit.

Entwicklung

Differenzierungen und Variationen

Simula

Die Objekt-Orientierte Sprache Simula wurde ursprünglich als eine Sprache konzipiert die spezielle Simulationen bewerkstelligen sollte. Man hatte damals das Ziel durch Simulation die Wirklichkeit abzubilden und dadurch neue Erkenntnisse zu erlangen, bzw. zu verifizieren.
Entworfen wurde sie von Nygaard and Dahl.
1967
als Subset enthält sie Algol 60
Simula führt die Bezeichnung "Klassen" und "Objekte" ein.

Smalltalk

Entwickler: Alan Kay, Dan Ingalls, and Adele Goldberg
1970
keine strenge Typisierung. Eine auf Klassen basierte Sprache ohne mehrfache Vererbung.

Modula-3

Entwickler waren Luca Cardelli, Jim Donahue, Mick Jordan, Bill Kalsow, Greg Nelson.
1989
In dieser Sprache gibt es keine explizite Typen-Definitionen und Deklarationen.
Es ist dies eine Sprache mit strenger Typisierung ohne automatischer Umwandlung.

Self

Entwickler: David Ungar und Randall Smith.
1987
Diese Sprache verwendet Prototyp-Objekte sowie Klonen um neue Objekte zu erstellen.

Eiffel

Entwickler: Bertrand Meyer
1986.
Eiffel ist eine Sprache die mehrfache Vererbung unterstützt, strenge Typisierung

C++

Bjarne Stroustrup
“C mit Klassen'' entstand 1980
1983
strenge Typisierung , starker Einfluss von C und Smalltalk.
templates, method overloading, exceptions, threads
Hybrid Sprache (zu C kompatibel)

Java

James Gosling
1993, herausgegeben 1995
Eine durch das Internet groß gewordene Sprache.
Kleiner Kern, sicher, plattformunabhängig, Netzwerkfähig (RMI) Remote Method Invocation

Objektorientierte Softwareentwicklung / Bertrand Meyer. Aus dem Amerikan. übers. von Werner Simonsmeier . - München [u.a.] : Hanser [u.a.] , 1990 . - XXVI, 547 S.
und: Survey of Object Oriented Programming Languages

Reifung und Klärung der Kernvorstellung

Der "Vater" der Objekt Orientierten Sprachen (in diesem Fall Smalltalk), Alan Kay stellte sich einen idealen Computer wie einen lebendigen Organismus vor. In diesem sollten Zellen zusammenarbeiten um eine Aufgabe gemeinsam zu Lösen, sie sollten sich aber auch umgruppieren können um sich an die Problemstellung anpassen zu können. Die Zellen sollten Nachrichten austauschen können. Eine Analogie zur OOP.
Alan Kay (by Scott Gasch)

"A design can be Object Oriented, even if the resulting program isn't."

"A program can be Object Oriented, even if the language it's written in isn't."

Madsen, Ole Lehrmann "What object-oriented programming may be - and what it does not have to be" Lecture Notes in Computer Science Ed: G. Goos and J. Hartmanis - 1988

Objektorientiertes Programmieren beginnt mit der Auswahl der richtigen Sprache, aber muss auch das Softwaredesign und den Entwicklungsvorgang umfassen. Die richtige Sprache zu finden ist nicht einfach, um OO Programmieren zu lernen ist wohl der Gebrauch mehrerer Sprachen mit verschiedenen OO Ansätzen das beste.
Gerade am Beispiel C++, sieht man wie leicht es ist mit einer OO Sprache nicht OO zu Programmieren. Fast alle gültigen Programme in C sind auch in C++ gültig. Durch die rückwärts - Kompatibilität wird das OO Design aufgeweicht.

"...object oriented programming will be in the 1980's what structured programming was in the 1970's. Everyone will be in favor of it. Every manufacturer will promote his products as supporting it. Every manager will pay lip service to it. Every programmer will practice it (differently). And no one will know just what it is."

Nguyen, Van and Hailpern, Brent "A Generalized Object Model" ACM SIGPLAN NOTICES - v17, n9 Ed: G. Richard Wexelblat - September 1982

Verschiedene Auffassungen was OO heißt. Apple erfindet OO-Interface. Durch das vereinfachte Programmieren von User Interfaces entsteht der Eindruck, dass OO Programmieren gerade das Bedeutet. Die Idee der Bindung von Objekten am Bildschirm mit Metaphern aus der Wirklichkeit (z.B. Desktop, Papierkorb). Allerdings sind diese Objekte ja nicht unbedingt als eine Klasse/Objekt programmiert.

Object-oriented versus conventional construction of user interface prototyping tools / Wolfgang Pree . - Wien : VWGÖ , 1992 . - V, 169 S. . - (Dissertationen der Johannes-Kepler-Universität Linz ; 90 )

Der entstehende Hype rund um OO bremst die Weiterentwicklung. Die Konzentration auf Hybride Sprachen beeinträchtigt die Entwicklung des OO Kerns. Es gibt Stimmen die zur Besinnung auf die ursprünglichen Konzepte von Smalltalk aufrufen.
(Rachid Guerraoui ECOOP '98)

Die Entwicklung ist bei weitem nicht Abgeschlossen, ersichtlich an der großen Anzahl an verfügbaren Sprachen und Sprach-Konzepten.

Umsetzung und Verbreitung

C++ wird durch seine Kompatibilität mit C (um maschinen-spezifischen Code zu schreiben) und durch die Verbreitung von Unix / Linux bekannt.
Java wird am Anfang seiner Entwicklung ignoriert. Erst durch die Verbreitung des Internets ergibt sich eine Marktlücke. Durch sein sicheres Sandkasten-System sowie der Erweiterungen der Sprache, die sie sehr Netzwerkfähig machen, wird es beliebt.
Eine schnelle Verbreitung für Java Internet-Applikationen durch hohe Portabilität verhalf dieser Sprache zu ihrem Durchbruch.
Modula fand geringere Verbreitung als Pascal. Ada wurde bei militärische Anwendungen der USA verwendet.
Eine Erkennung von Fehlern zur Übersetzungszeit wird von Sprachen mit strenger Typisierung besser verwirklicht.

Reaktionen

Akzeptanz

Es ist eine sehr hohe Akzeptanz feststellbar. Viele Sprachen folgen dem "Hype" und werden Objekt - orientiert.
Seit Ende der 80er Jahre ist eine stark zunehmende Verbreitung in Ausbildung und Industrie festzustellen.
Gründe sind vor allem die Wiederverwendung und bessere Erweiterbarkeit jedoch werden die Vorteile nur bei vollständiger Umstellung des Softwareentwicklungsprozesses wirksam (objektorientierte Analyse, objektorientierter Entwurf, ...).
Konzepte und Vorteile der Objektorientierten Programmierung:

Designprozess wird OO Booch, Rumbaugh und Jacobson entwickeln UML (ver. 1.0 in 1997)

Scheitern

Gescheitert ist die OOP einstweilen noch nicht, aber durch den teilweise übertriebenen Hype kam es zu überzogenen Erwartungen. Die Realen Vorteile, Wiederverwendung von Code, verringerte Implementierungszeit, Erleichterungen in der Wartung usw. wurden überbewertet oder überschätzt.

"Object Oriented Development (OOD) has been touted as the next great advance in software engineering. It promises to reduce development time, reduce the time and resources required to maintain existing applications, increase code reuse, and provide a competitive advantage to organizations that use it. While the potential benefits and advantages of OOD are real, excessive hype has lead to unrealistic expectations among executives and managers. Even software developers often miss the subtle but profound differences between OOD and classic software development."
Potential Pitfalls of OOD

Probleme

Kleine Änderungen im Code können zu Grossen und nicht lokalen Effekten führen. Durch Vererbung und "dynamic dispatch" ergeben sich schwer abschätzbare Folgen.
Dieselben Methoden machen auch das verstehen des Daten- und Programmflusses sehr schwierig.
Die bislang gebrauchten Debugger (mit break points) können quasi nicht mehr gebraucht werden, da der Zustand eines Systems nicht mehr anhand der Position im Programm festzustellen ist.

Proceedings of the 2001 ACM SIGPLAN - SIGSOFT Workshop on Program Analysis for Software Tools and Engineering
BarbaraG.Ryder and Frank Tip: "Change Impact Analysis for OO Programms" (s.46)

In schlecht strukturierten Domänen ist OO schwach. Dies trifft immer dort zu, wo sich die Realität nicht (leicht) in ein OO - Design Abstrahieren lässt.
OO - Denken ist dem Menschen nicht so "angeboren" oder natürlich wie viele glauben.

critiqueof the Object Oriented Paradigm: Beyond Object-Orientation, By Shajan Miah

Einfache Textbuch- Beispiele lassen sich nicht immer auf die Realität übertragen..

Wie aber ordnen wir Funktionalität den Objekten zu? Wo ist das SINGLE BEST HOME für unsere Operationen?
Wohin mit den Funktionen im Objektmodell?" Peter Hruschka here

Kritik

Es gibt auch Kritiker die sich nicht auf einzelne Aspekte der OOP beziehen sondern sie als ganzes kritisieren.
Kritikpunkte sind die nicht eintretenden wollenden postulierten Vorteile (OOP muss nicht funktionieren). Die erhöhte Komplexität, der Lernaufwand. OOP wird kritisiert da es als "Allheilmittel" gesehen wird und dadurch die Entwicklung von Alternativen gehemmt wird.

Critique of Bertrand Meyer's Object Oriented Software Construction, Findy Services and B. Jacobs

Rettungsversuche

Unter "Rettungsversuch" würde ich eine realistische Einschätzung der Vorteile von OOP verstehen. Dies wird aber sicher mit längerem Gebrauch dieses Paradigmas notwendig werden.

OOP is not a panacea. It will not serve as a floor wax and a dessert topping under all circumstances. It's just better than the current alternatives."
Peter Deutsch, OOPSLA '89

Zur Entstehung der deklarativen Konzepte

Seit den fünfziger Jahren werden Programmiersprachen unterschiedlicher Konzepte und Stile entwickelt und angewendet. Je nachdem welche Verfahrensklassen bzw. Maschinenarchitekturen zugrunde gelegt werden, sind verschiedene Sprachkonstrukte und Programmierparadigmen entstanden. Nachfolgende Skizze zeigt die

Logische und funktionale Programmiersprachen werden zusammenfassend häufig auch als deklarative Sprachen bezeichnet. Obwohl erste Ansätze zu funktionalen Sprachen mit LISP bereits vor 1960 als Listenverarbeitungssprachen mit imperativen Bestandteilen eingeführt wurden, entstanden deklarative (rein funktionale bzw. logische) Sprachen in den 70er Jahren im Zusammenhang mit der sogenannten Softwarekrise. Einerseits war die Komplexität der zu implementierenden Verfahren so stark gestiegen, daß der Entwicklungsaufwand der imperativen Programme unvertretbar hoch und die Programme selbst nicht mehr vollständig prüfbar waren. Insbesondere die Softwaresicherheit war nicht zu gewährleisten. Deshalb wurden Sprachen untersucht, deren Programme korrekt spezifizierbar und verifizierbar sein sollten. Damit entstanden die deklarativen Sprachen. Daneben wurde die Objektorientierung eingeführt, bei der Datentypen und Aktionen als Bestandteile eines Objektes zusammengefaßt wurden.

Gegenwärtig besteht der Trend funktionale und logische Bestandteile in einer deklarativen Sprache zu vereinigen und dabei auch Objektorientierung zu berücksichtigen.

Objektorientierung versus deklarative Konzepte

– Eine psychologische Betrachtung

Glaubt man einschlägigen psychologischen Untersuchungen und Forschungen, so ist der Objektorientierte Ansatz jener, welcher der Arbeitsweise des menschlichen Gehirns bzw. der menschlichen Psyche am nächsten kommt.

Dieser Umstand kann bei der Durchsetzung gegenüber anderen Praradigmen eine nicht zu vernachlässigende Rolle gespielt haben bzw. spielen.

Verhalten beobachten, alle Dinge zunächst danach zu beurteilen, was man mit ihnen

machen kann. So ist z.B. ein Schraubenzieher ein Werkzeug, mit dem man in erster Linie

Schrauben lösen und festziehen kann; als Vertreter einer Klasse mit allgemeineren Eigenschaften wie „länglich“, „spitz“ kann man ihn zur Not aber auch als Brechstange, Meißel, Bohrer oder Stichwaffe verwenden. Umgekehrt unterscheidet man diverse Teilklassen mit spezielleren Merkmalen: Schraubenzieher für Schlitzschrauben, für Kreuzschlitzschrauben, mit Einrichtung zur Spannungsprüfung usw. Gerade Kleinkinder besitzen in hohem Maße die Fähigkeit zwischen den Ebenen dieser Hierarchie hin und her zu wechseln und dabei Eigenschaften und Operationen von Objekten zu entdecken, die sie für einen völlig anderen als ihren vorbestimmten Zweck geeignet erscheinen lassen. An diesem Beispiel konkretisiert sich bereits die klassische objektorientierte Denkweise.

Ausgehend von einer Reihe von Untersuchungen zur Problemlösefähigkeit und den verfügbaren Problemlösemethoden von Menschen in der ersten Hälfte dieses Jahrhunderts

gibt es eine Vielzahl von Untersuchungen bei Kindern und Erwachsenen über die Wahrnehmung von Objekten und die Repräsentation von Wissen sowie darüber, wie dieses Wissen menschliche Entscheidungen und Handlungen leitet. Alle diese Untersuchungen belegen, daß Menschen Objekte überwiegend anhand der Handlungen identifizieren, die mit ihnen möglich sind, als anhand äußerlicher Eigenschaften wie Farbe oder Form. Wichtige Bausteine dieser psychologischen Theorie sind die sog. Schemata oder Kategorien, das sind große komplexe Einheiten, die wesentliche Teile menschlichen Wissens und Verhaltens organisieren. Aus Sicht der objektorientierten Programmierung handelt es sich bei den Schemata oder Kategorien um Klassen.

Das folgende Experiment verdeutlicht diese Überlegungen: Mehrere Versuchspersonen,

an einer Wand in Augenhöhe nebeneinander drei Kerzen zu befestigen und anzuzünden.

Hierfür standen den Probanden eine Reihe von willkürlich auf dem Tisch verteilten Gegenständen zur Verfügung. Unter den meist nutzlosen Dingen befanden sich auch einige für die Lösung brauchbare: Heftzwecken, Streichhölzer und drei kleine in Farbe und Größe

Lösung der Aufgabe: Mit je einer Heftzwecke werden zunächst die Pappschachteln an der

Wand befestigt; sie dienen den Kerzen als Standflächen. Anschließend werden die Kerzen

Die Versuchspersonen mußten diese Aufgabe in zwei leicht unterschiedlichen Ausgangssituationen lösen: Bei den Personen der ersten Gruppe waren die drei Pappschachteln mit Versuchsmaterialien gefüllt, die erste mit den Kerzen, die zweite mit Heftzwecken und die dritte mit Streichhölzern. Bei der zweiten Gruppe waren die Schachteln leer; Kerzen, Heftzwecken und Streichhölzer lagen hier auf dem Tisch verstreut.

Erstaunlicherweise wurde die Aufgabe von der zweiten Gruppe signifikant häufiger und

schneller gelöst als von der ersten. Duncker erklärt dieses Ergebnis wie folgt: Die erste

Gruppe nimmt die Schachteln als Behälter für Kerzen, Heftzwecken und Streichhölzer

wahr. Diese Funktion „Behälter“ ist anschließend so eng mit den Schachteln verknüpft,

daß die Probanden ihr Denken kaum noch davon lösen können und unfähig sind, die

Schachteln zu einem völlig anderen Zweck zu nutzen, nämlich als Standfläche für die

Kerzen. Duncker nennt dieses Phänomen funktionale Gebundenheit. Die zweite Gruppe

nimmt die Schachteln ohne die Bindung an eine spezielle Funktion wahr. Die Versuchspersonen können sie daher völlig frei auch zu scheinbar ungewöhnlichen Zwecken (als Standfläche) einsetzen.

Was bedeuten diese Beobachtungen aus Sicht der Programmierung? Die Versuchspersonen

denken offenbar objektorientiert: Gegenstände werden zuerst unter dem Gesichtspunkt

in Klassen eingeteilt, welche Operationen mit ihnen möglich sind. Eine Schachtel

gehört damit für die erste Gruppe zur Klasse der Objekte, auf denen Operationen wie

„öffnen“ und „schließen“ erlaubt sind und die einen Zustand wie „leer“ oder „gefüllt“ besitzen.

Gegensatz zur zweiten, daß Schachteln auch als Objekte einer Oberklasse mit allgemeineren

Eigenschaften aufgefaßt werden können, etwa als Objekte der Klasse quaderförmiger,

flacher Gegenstände mit Operationen wie „als Unterlage verwenden“, „stapeln“

usw. Funktionale Gebundenheit ist aus objektorientierter Sicht also die mangelnde Fähigkeit, zwischen unterschiedlichen Verfeinerungen einer Klassenhierarchie gedanklich hin und her zu wechseln.

In diesem Versuch von Duncker wurden das Denken und die Problemlösefähigkeit durch

die objektorientierte Vorgehensweise mehr oder weniger behindert. Dies spricht nur auf

den ersten Blick gegen die objektorientierte Denkweise. Vielmehr scheint diese Denkweise,

also das Kombinieren der Eigenschaften und Operationen, die lokal mit den Objekten

verbunden sind, im Mittel schnell zu akzeptablen Lösungen zu führen. Sonst hätte sich

die Denkweise im Laufe der menschlichen Evolution vermutlich auch nicht durchgesetzt.

Denkfehler wie in obigem Versuch gilt es, durch Problemlösetraining zu vermeiden.

Entstehungskontext