Aus : Schubert / Schwill, 2004, S. 212 -
216
7.2 Entwicklung und Bedeutung
Der Begriff "objektorientierte
Programmierung (OOP)" wird in verschiedenen Bedeutung verwendet. Das führt
zu ähnlichen Missverständnissen, wie sie vom Prinzip der strukturierten
Programmierung ausgingen (Schubert, 1991). Wenn man den Prozess des OOM
unterteilt in:
•
objektorientierte Analyse (OOA),
•
objektorientierter Entwurf (OOE),
•
objektorientierte Programmierung (OOP),
dann meint man die Programmierung im engeren
Sinne, also die Übertragung des Entwurfes in die Programmiersprache (auch
Kodierung genannt). In der Fachwissenschaft Informatik ist es üblich, mit
Programmierung den gesamten Problemlösungsprozess (Analyse, Entwurf und
Programmierung (Kodierung)) zu bezeichnen. In der Lehrdisziplin Informatik
setzt sich zunehmend der Begriff informatische Modellierung für den
fachspezifischen Problemlösungsprozess als Ganzes durch. Wir bezeichnen deshalb
das Prinzip der objektorientierten Programmierung mit OOM. In den
Zitaten wird OOP in diesem Sinne verwendet. Zur Bedeutung der OOM wird die
Sichtweise aus dem Schülerduden Informatik übernommen:
"Daher lässt sich die objektorientierte
Programmierung zusammen mit der strukturierten Programmierung, als deren
Fortsetzung sie aufgefasst werden kann, eher in die Klasse der
Software-Entwicklungsmethoden als in die Klasse der programmiersprachlichen
Denkschemata einordnen" (Claus/Schwill, 1997, S. 382).
"Programmiersprachliches Denkschema"
wird im Folgenden kurz Paradigma genannt. Man unterscheidet das prozedurale
und deklarative (fasst funktional und prädikativ zusammen) Paradigma. In der
Informatik werden nach wie vor alle Paradigmen angewendet. Für jede
Aufgabenklassse steht ein spezielles Paradigma im Vordergrund.
"Es gibt Problemstellungen, deren Umsetzung
geradezu nach objektorientierter Programmierung verlangen, z.B. im Bereich der
Simulation oder bei der Entwicklung graphischer Benutzeroberflächen, und
andere, bei denen das nicht der Fall ist. Insofern kann tatsächlich der Fall
eintreten, dass objektorientierter Entwurf und Programmierung das Problem nicht
löst und daher nicht 'funktioniert'" (Claussen, 1993, S. 2-3).
Es besteht keine Notwendigkeit, erfolgreiche
prozedurale und deklarative Informatiklösungen objektorientiert nachzubauen.
Die Informatik besitzt eine lange Tradition im Entwickeln effizienter
Algorithmen. Diese Erfahrungen dürfen in der informatischen Bildung nicht
fehlen. OOM sollte also dort einsetzen, wo bessere Lösungen damit erzeugt
werden können.
OOM stützt sich heute ebenso wie das Prinzip der
strukturierten Programmierung auf das prozedurale Paradigma, denn Operationen
werden auf diese Weise realisiert. Das mag eine Zwischenstufe der Entwicklung
sein, die noch überwunden wird. Es zeigt uns aber zwei wichtige Konsequenzen.
Erstens ist OOM keineswegs so homogen in der Denkweise, wie behauptet wird.
Zweitens gehört zur informatischen Bildung das Verständnis dafür, dass das
informatische Modellieren
"... eine geschichtliche Entwicklung
durchlaufen hat und sich noch immer weiterentwickelt. ... Die Richtung, in der
die geschichtliche Entwicklung abgelaufen ist, war sicher kein Zufall"
(Böszörmenyi, 2001, S. 15).
Für die Schüler ist es also außerordentlich
wichtig, verschiedene Problemlösungsansätze der Informatik kennen und
vergleichen zu lernen. So kann z.B. das deklarative Paradigma mit der
Software-Entwicklungsmethode des strukturierten Wachstums verbunden werden. Die
Schüler erkennen, dass die Transparenz umfangreicher Wissensbasen (aus Fakten
und Regeln) bzw. komplizierter Funktionengeflechte unterstützt werden muss.
Trace-Mechanismen und Erklärungskomponenten veranschaulichen die
Ableitungspfade. Wir empfehlen, zwei Paradigmen im Informatikunterricht
vorzustellen. Bisher liegen gute Erfahrungen zur gestaffelten Einführung in
das prozedurale (als erstes) und prädikative (als zweites) Paradigma unter
Bedingungen eines Zentralabiturs vor. Für andere Kombinationen fehlt bisher die
vergleichbare Lernerfolgskontrolle. Beide Paradigmen können unterschiedlich
tief angeeignet werden. Das Bildungsziel eines Sichtenwechsels steht im
Vordergrund, nicht die Lösung komplexer Konstruktionsaufgaben.
Abstraktion spielt in der Fachwissenschaft eine
andere Rolle als in der Lehrdisziplin Informatik. Im Fach vereinfacht
Abstraktion die Entwicklungsprozesse von Hard- und Software. Sie muss nur
einmal richtig verstanden werden. Dieses Verständnis hat die Lehrdisziplin zu
fördern. Gerade dabei zeigen sich große Schwierigkeiten. Deshalb muss der
Aneignungsprozess mit sehr anschaulichen Einzelbeispielen beginnen. Die
Anforderungen an die Abstraktion dürfen nur schrittweise erhöht werden. Genau
so ist auch die historische Entwicklung in der Informatik verlaufen. Ein Grund
mehr, den historischen Lernansatz zu verfolgen.
Die These von der Weiterentwicklung der
strukturierten Programmierung wird für die Schüler verständlich, wenn man die
Vorstufen der OOM näher betrachtet. Ihre Thematisierung im Informatikunterricht
entspricht einer Linie mit steigender Abstraktion und beantwortet die Frage zum
Entwicklungsstand der Informatik. Zur Komplexitätsbewältigung und der damit
verbundenen Fehlerreduzierung wurde die funktionale Abstraktion als
Grundkonzept zur Beschreibung benutzerdefinierter Operationen entwickelt. Die
Schüler lernen die Möglichkeit zur Konstruktion wieder verwendbarer
Lösungsbausteine im prozeduralen Paradigma in Form von Prozeduren und
Funktionen kennen. Bei der Anwendung treten häufig Probleme im Verständnis des
Parameterkonzeptes auf. Die Entscheidung für Wert- und Referenzparameter
erfordert ausreichendes Wissen um die damit verbundenen Konsequenzen. Als
Lernhilfe wurde z.B. das Modell eines Hauses mit verschiedenen Räumen
vorgestellt, an deren Türschildern man die aktuellen Parameterbelegungen
ablesen kann, die jeweils im Rauminneren erzeugt wurden. Das erwies sich bei
Referenzparametern eher als Hürde im Lernprozess.
Da Kapselung ein wichtiges Prinzip der
Informatik ist, lohnt es, den Entwicklungsweg transparent zu machen und die
Etappen zu beurteilen:
1.
Etappe: Subroutinen konnten
Befehlsfolgen einer maschinenorientierten Programmiersprache unter einem Namen
zur Wiederverwendung bereitstellen. Die dabei verwendeten Daten blieben jedoch
ungeschützt, da sie noch nicht gekapselt werden konnten. Sie waren global
verfügbar, d. h. sie existierten während der gesamten Ausführungszeit des
Programms. Benutzerdefinierte Datentypen waren noch unbekannt.
2.
Etappe: Eine Weiterentwicklung des Konzeptes führt zur funktionalen
Abstraktion. Sie wird in Form von Unterprogrammen, Funktionen oder Prozeduren,
realisiert. Operationsfolgen und Daten werden gemeinsam gekapselt. Damit liegen
lokale Daten vor. Lokal sichtbare Daten existieren nicht über die
Ausführungszeit der Funktionen und Prozeduren hinaus. Der Datenaustausch
erfolgt mittels Parameterkonzept über eine definierte Schnittstelle. Die
formalen Parameter werden vor der Ausführungszeit vereinbart. Die aktuellen
Parameter entstehen zur Ausführungszeit. Es fehlt die Möglichkeit, lokale Daten
über die Ausführungszeit der Funktionen und Prozeduren hinaus zur Verfügung zu
stellen, ohne diese außerhalb der Kapselung aufzubewahren.
3.
Etappe: Eine Datenkapsel kann als nächster Schritt zur
Verbesserung des Konzeptes verstanden werden. Die benutzerdefinierte
Datenstruktur, wird zusammen mit den Operationen, die auf dieser Datenstruktur
ausgeführt werden sollen, gekapselt. Dabei wird festgelegt, welche Daten von
außen sichtbar sein dürfen und welche verborgen werden. Die Programmiersprache
Modula stellt Datenkapseln zur Verfügung. Als nachteilig erwies sich, dass nur
genau ein Exemplar einer solchen Struktur beschreibbar ist. Es fehlt also ein
Konzept, das den Export eines Datentyps ermöglicht.
4.
Etappe: Mit dem abstrakten Datentyp (ADT) wurde das möglich. Die
Vorteile bestehen darin, dass:
-
beliebig viele Exemplare (Instanzen) vom Typ ableitbar sind.
- ein
hoher Grad der Abstraktion für benutzerdefinierte Datentypen erreicht wird.
Es bleibt der Nachteil, dass keine Ableitungen
von Typen aus einem Basistyp möglich sind.
5.
Etappe: Die Fortsetzung des Konzeptes führte vom ADT zur Objektorientierung.
Eine Klasse entspricht einem ADT. Jedes Objekt entsteht durch Inkarnation
aus einer Klasse (Bauplan für eine Objektart). Eine Klasse beschreibt
Instanzvariablen (gekapselte Datenstruktur in den Objekten) und die über den
Variablen definierten Operationen. OOM bietet mit der Vererbung die
Möglichkeit, aus einem Basistyp neue Typen abzuleiten. Schnittstelle und
Funktionalität des Basistyps gehen auf den abgeleiteten Typ über. Es besteht
die Möglichkeit zur Modifikation des abgeleiteten Typs.
Die Schüler verstehen OOM nun als eine
Entwicklungsstufe des informatischen Modellierens, die nicht zufällig entstand,
die aber auch keinen Abschluss bilden kann, denn Vererbung verstößt gegen das Geheimnisprinzip.
Im Informatikunterricht der Sekundarstufe II erwies
sich das Konzept des ADT als erlernbar. Solange keine Informatikvorkenntnisse
aus der Sekundarstufe I vorlagen, sahen die
Lehrpläne vieler Bundesländer genau ein Paradigma der Informatik, das
prozedurale Paradigma, vor. In diesem wurde das erforderliche Abstraktionsniveau
systematisch bis zu ADT und dynamischen Datenstrukturen über die möglichen
Kurse entwickelt. Bei der Euphorie über das hohe fachliche Niveau in einem
Teilgebiet der Informatik wurde übersehen, dass zunehmend weniger Schüler
bereit waren, ein Fach zu wählen, in dem es sehr schwer ist, Spitzenleistungen
zu erzielen. Die Überlegungen der Schüler zu ihrer Abiturstrategie zeigten,
dass Informatik im Wettbewerb mit anderen Fächern bestehen muss. Bei der Suche
nach neuen, attraktiven Konzepten bot sich OOM an. Außerdem versprachen
Fachwissenschaftler große Erleichterung in der Software-Entwicklung durch Anwendung
der OOM. Hier kann es leicht zu Fehleinschätzungen des Lernaufwandes für OOM
gekommen sein. Inzwischen wird OOM in den Lehrplänen einiger Bundesländer
empfohlen. Die Ablösung des prozeduralen Paradigmas durch OOM wurde gefordert
(Czischke, 1997). Die notwendige Fähigkeit, Operationen mit prozeduralen
Strukturen zu gestalten, eignen sich die Schüler bei dieser unterrichtlichen
Vorgehensweise im Kontext der OOM an. Wenn man die folgende These als korrekt
annimmt, dann wird OOM keineswegs leichter erlernbar sein, als das Basiskonzept
ADT.
"Objektorientierter Entwurf ist die
Entwicklung von Softwaresystemen als strukturierte Sammlung von
Implementierungen abstrakter Datentypen" (Claussen, 1993, S. 15).
Die beschriebene bessere Motivationslage der
Schüler kann durchaus andere Ursachen haben. So kann die Begeisterung der
Lehrer für OOM einen wichtigen Einfluss auf ihren Unterricht ausüben. Eine
Evaluierung der Lernprozesse zu alternativen Vorgehensweisen beim
informatischen Modellieren steht noch aus. Sie wird erschwert durch die
geringen Schülerzahlen im Informatikunterricht. Ob die objektorientierten
Denkweisen den lehrmethodisch günstigsten Zugang zum Verständnis der
Informatik bilden, bleibt vorerst offen. Es gibt deutliche Gegenstimmen:
"Dabei wird übersehen, dass
Objektorientierung kaum für den Einstieg in die Informatik geeignet ist (Hartmann/Nievergelt,
2002, S. 467).
Wir empfehlen, unterschiedliche Arten der
informatischen Modellierung zum Lerngegenstand zu machen. Jeder Eindruck eines
universellen Problemlöseansatzes ist zu vermeiden. Ein ausgewogenes
Verständnis der Informatik muss Vorrang vor sehr speziellen Bildungszielen
bekommen (Humbert, 2003). Insgesamt darf das informatische Modellieren nicht
den Informatikunterricht ausfüllen. Es besteht keine Notwendigkeit, große
Informatiksysteme im Unterricht mit Schülern zu entwickeln, um deren
Wirkprinzipien und Architektur als Lerngegenstand zu gestalten. Die Lernzeit
für die Analyse von anwendungstauglichen Informatiksystemen wird häufig
unterschätzt. Wir empfehlen deshalb, Strukturmodelle im Unterricht
einzusetzen, um Entwurf und Funktionalität von Informatiksystemen zu vermitteln
(vgl. Kapitel 9).