5.Objektorientierte Programmierung mit C#

5.Objektorientierte Programmierung mit C# 1. Theoretische Grundlagen der OOP In diesem ersten Kapitel 5.1 werden Sie die von einer Programmiersprache weitgehend unabhängigen Prinzipien der objektorientierten Programmierung kennenlernen. Erschrecken Sie nicht über so viel Theorie, seien Sie auch nicht verzweifelt, wenn Ihnen manches zunächst unverständlich bleibt: Spätestens wenn wir die Technik in den folgenden Kapiteln einsetzten, werden Sie nach und nach auch dieses Kapitel als Wörterbuch schätzen lernen! Klarstellung zu Beginn Man kann sich 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 wir aber in der Schule kaum schreiben! 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. Ergänzen möchte ich: OOP ist eine Möglichkeit, die Realität zu modulieren, - keinesfalls aber immer die günstigste! Wie Sie in Kapitel 2 gesehen haben, erleichtert ein gelegentlicher Paradigmenwechsel die Arbeit des Programmierens erheblich. Mit Haskell benutzt man das funktionale, mit Prolog das deklarative und mit PHP das prozedurale Paradigma. Diese und viele weitere Programmiersprachen kommen völlig ohne OOP aus! Bei solch gewichtigen Argumenten wird es Sie verwundern, dass wir der OOP dennoch ein ganzes Kapitel gewidmet haben. Die Gründe dafür: Zum Verständnis des objektorientierten Paradigmas werden fast alle Kapitel des dreijährigen Informatikunterrichts (http://www.ningelgen.eu/05_informatik/index.html ) berührt. Die Modulierung realer Objekte durch OOP ist anfangs verblüffend einfach. Kein anderes Programmier-Paradigma ist so nah an der Realtiät! 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. 442

Welche Programmiersprache? Nachdem Sie in Kapitel 2 schon erste Schritte in den objektorientierten Sprachen Java, Delphi und C# unternommen haben, liegt es nahe, dieses Kapitel mit einer der drei Sprachen durchzuziehen. Man kann, wie hier im ersten Teil des Kapitels, OOP auch ganz losgelöst von einer konkreten Programmiersprache behandeln, aber dann wird die Sache etwas trocken! Etwa so wie in einer Fremdsprache, in der man ausschließlich die Grammatik, oder noch schlimmer, die Philosophie der Grammatik diskutiert! Das vorliegende Kapitel 5 habe ich vor einigen Jahren für Delphi geschrieben. Leider hat die Firma Borland, die Delphi entwickelt, inzwischen ein derartig restriktives und schwer zu installierendes Lizenz-Modell für Schulnetze, dass ein Wechsel zu einer anderen Sprache angezeigt erschien. Außerdem sind die, für private Nutzer kostenlosen Standard-Versionen, inzwischen so eingeschränkt, dass man selbst im gymnasialen Schulalltag an Grenzen stößt. (Beispiel: Datenbanken!). Wünschenswert wäre natürlich auch eine Unterstützung der Klassenbibliothek.NET, eine möglichst umfangreiche Hilfsfunktion und einen problemlos zu bedienenden Editor. Natürlich muss die Sprache kostenlos, möglichst uneingeschränkt, und leicht zu installieren sein. Wie Sie der Überschrift des Kapitels entnehmen, viel die Wahl auf C# (Visual C# 2010 Express). Immer dann, wenn es dem besseren Verständnis dient, werden wir dennoch auf die Lösungen in Delphi und Java hinweisen. Voraussetzung für Kapitel 5 ist daher Kapitel 2.02. Es genügt auch schon, wenn dort der Teil über Visual C# und.net durchgearbeitet wurde. Aufgabe 1 Informieren Sie sich im Internet über die ebenfalls im Visual Studio Express (Microsoft) angebotenen objektorientierten Programmiersprachen C++ und VB und schreiben Sie die Ergebnisse Ihrer Recherche direkt ins Skript. Historisches 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. 443

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 objetkorientierten Programmiersprachen. (Der Name OOP entstand allerdings erst später). Man muss sich klar machen: Zu dieser Zeit war Pascal noch nicht einmal angedacht! Mit der Sprache Smalltalk wurde anfang der 70-er Jahre das Modellierungs-Konzept aus Simula verfeinert. Insbesonder war dies die Idee, bereits fertige Konzepte wiederzuverwenden. Ein typisches Beispiel: Betrachten Sie einen klassischen Button auf einem Formular. Hat man den einmal erzeugt, so können alle weiteren graphischen Schaltflächen, die dem Button ähnlich sind, aus dem Ur-Button abgeleitet werden und muss nicht neu erfunden werden. Und genau daraus entseht die Idee, fertige Konzepte weiterzuvererben. Da es in der Realität eine unübersehbare Menge an Objekten gibt, die vielleicht irgendwann nutzbringend modelliert werden könnten, muss dem Programmierer die Möglichkeit gegeben werden, eine möglichst vollständige Erweiterbarkeit bei Datentypen zuzulassen. Man spricht in diesem Zusammenhang von einem abstrakten Datentyp (ADT). Dieser wurde erstmals in (sehr akademischen) Programmiersprachen Eifel und Oberon verwirklicht. 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++. Gut, - C++ ist nun nicht gerade ein Musterbeispiel der OOP, aber dennoch: Man kann damit oo programmieren! Dass die prozedurale Methode dort auch noch erlaubt ist, wird ja nur von den Puristen verachtet! Heute sind die wichtigsten objektorientierten Programmiersprachen zweifelsohne 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. Oder anders formuliert: Wie schlecht wäre Vista erst ohne OOP ;-) Zur Modellierung verwendet man hier übrigens keine Flussdiagramme, sondern sprachenunabhängig UML (Unified Modelling Language). Mit Hilfe von Diagrammen wird hier die Abhängigkeit der Objekte mit ihren Strukturen dargestellt. Ein gutes Werkzeug hierfür sind die Fujab-Tools. ( http://wwwcs.uni-paderborn.de/cs/fujaba/ ) In dem folgenden Bild aus Wikipedia können Sie nochmals die geschichtlichen Zusammenhänge studieren. 444

Ein Detail am Rande: Anders Hejlsberg hat sowohl Objet-Pascal (Grundlegender Code für Delphi) als auch C# entwickelt. Wenn es einen Nobelpreis für Informatik gäbe: Er hätte ihn verdient!! Aufgabe 2 Es gibt natürlich noch weitere Programmierparadigmen. Hier die wichtigsten: Strukturierte Programmierung Aspektorientierte Programmierung Generative Programmierung Informieren Sie sich über mindestens eines dieser Paradigmen und untersuchen Sie dabei die Frage, ob es der objektorientierten Programmierung entgegensteht oder sie sogar ergänzt. (Tipp: Wikipedia) 445

Sprachliches Eine der eigentlich vermeidbaren Schwierigkeiten der OOP ist die Unmenge an Synonymen. Das mag mitunter an der ungenauen Übersetzung liegen. Weshalb manche Autoren allerdings object mit Instanz übersetzen, bleibt wohl deren Geheimnis. Es existieren zu viele verschiedene Begriffe, die alle das Gleiche meinen! Das ist die eine Seite der Medaille. Auf der anderen Seite und das ist weitaus schlimmer - gibt es gleiche Begriffe, die verschiedenes bedeuten! Was der Erste Feld nennt, nennt der Zweite Attribut. Unter einem Attribut versteht der Erste jedoch das, was der Zweite Datum nennt... Gibt es denn keine Normierung, was all die Begriffe und ihre Bedeutung angeht? Keine Sorge, die gibt es: Die Interface Description Language IDL. IDL-Standard Namen Klasse Objekt Feld Attribut Operation Parameter Einige Synonyme zum IDL-Standard gebräuchliche Synonyme Objekt Instanz, Exemplar Attribut, Eigenschaft Datenfeld, Datum, Feld (Member-)Funktion, Methode, Aktion, Routine oder Prozedur Argument, Variable Leider vereinfacht die obige Tabelle den Sachverhalt. (Als ob die Situation nicht schon kompliziert genug wäre!) Nicht immer sind die Begriffe in der zweiten Spalte echte Synonyme zur ersten Spalte. Vielmehr gibt es einen feinen, philosophischen Unterschied zwischen manchen Begriffen. Aber: Wen interessiert das? Klare Antwort: Uns nicht!! Das war Geständnis Teil 1. Bringen wir es hinter uns. Daher jetzt sofort: Geständins Teil2: Wir verwenden die IDL-Standard Namen nicht zu hundert Prozent! Unverzeihlich, mag man da denken. Die Wahrheit aber ist: Niemand benutzt den IDL- Standard in Reinform! Da mag der König (Theorie) schimpfen und stampfen: der Fürst (verwendete Programmiersprache) ist halt näher am Volk! In C#, wie übrigens in den meisten anderen Programmiersprachen auch, wird beispielsweise statt des Namens Operation der Begriff Methode verwendet. Trösten kann Sie dass wir alle verwendeten Bezeichnungen konsequent benutzen. Es wird also keine Bezeichnungs-Synomyme in diesem Skript geben. dass alle Bezeichnungen sowohl theoretisch (in diesem), als auch praktisch (im nachfolgenden Kapitel) ausgearbeitet werden. 446

Objekte und Klassen Programmiersprachen unabhängig wollen wir nun möglichst genau beschreiben, was unter einem Objekt zu verstehen ist. Dabei werden wir (soweit möglich und sinnvoll) eine Objekt-Analogie aus der realen Welt betrachten. Sie soll uns helfen, die abstrakten Begriffe anschaulicher zu machen. Zunächst ist ein Objekt ein Bestandteil des Programms. Es besteht aus Feldern und Methoden. In den Feldern ist der Zustand des Objekts festgehalten, durch die Methoden wird das Verhalten des Objekts bestimmt. In der Regel sind die Felder von außen nicht erkennenbar. Dadurch sind diese Zustands-Daten geschützt. Allerdings erlaubt das Objekt, eine Anfrage zu stellen. Diese Anfrage ist nichts anderes, als dass von außen eine Methode des Objekts aufgerufen wird. Schematisch: Durch diese Anfrage wird die Methode aktiv und liefert dem Anfragenden, ohne nach außen zu zeigen, was im Inneren des Objekts vorgeht, als Antwort die gewünschten Daten. Um die neuen Begriffe etwas klarer zu machen, werden wir nun versuchen, ein reales Objekt (Röhren bzw CRT-)Fernsehapparat zu modellieren. Zunächst hat der konkrete CRT-Fernseher, 40 Zoll, (das Objekt der Klasse CRT- Fernseher) feststehende (Daten-)Attribute. Zum Beispiel die Größe der Bildschirmdiagonalen, die Gerätetiefe, die Farbe etc. Dies sind gewiss Felder, die sich durch eine Anfrage nicht ändern lassen, auch wenn dies durchaus wünschenswert wäre... Es gibt aber weitere Attribute: Eingestellter Kanal, Lautstärke, Helligkeit des Bildes. Häufig kann man hier einen bestimmten Wert, sagen wir zwischen 0 und 100 wählen. Damit das klappt, muss das Objekt Methoden haben, wie: Kanal wechseln, Lautstärke oder Helligkeit verändern und so weiter. Was genau an Änderungen der (physikalischen) Daten innen vorgenommen wird, weiß der Anfragende nicht. Er muss es auch nicht wissen. Felder, wie Stromstärke im Lautsprecher sind private und daher noch außen hin gekapselt. Das bedeutet, dass man von außen diese Werte nicht sehen und direkt beeinflussen kann. Die Zahl für die eingestellte Lautstärke (z.b. 45) ist nach außen sichtbar und somit public. Puristen unterscheiden noch zwischen Operationen und Methoden eines Objekts. Wenn sich die Lautstärke verändert hat, dann wurde offensichtlich die Operation Lautstärke verändern angewandt. Dazu kann es durchaus verschiedene (hier physikalische) Methoden geben. 447

Nehmen wir an, eine Elektronik-Firma baut einen neuen Fernsehapparat. Natürlich muss sie das Gerät dabei nicht neu erfinden! Selbst wenn sie nun den ersten LCD- Fernseher entwirft, sind doch viele Methoden und Felder gleich oder ähnlich wie beim alten CRT-Gerät. Daher tut man gut daran, wenn man zunächst möglichst allgemein eine Beschreibung für das Gerät Fernseher festschreibt. In OOP heißt eine solche abstrakte Beschreibung eine Klasse. Mit Hilfe der UML (= Unified Modeling Language) kann man sie grafisch darstellen. Wir verwenden hierzu das Programm UMLed 184 von Georg Kubitz. Unter Optionen wählen wir "Java-Version", weil das nach Java exportierte Programmgerüst C# sehr ähnlich ist. So sieht das Bild der abstrakten Klasse Fernseher mit der Klasse Fernbedienung (die eine Klasse Fernseher kennt) aus. Abstrakt nennt man die Klasse, weil ihre Methoden nicht explizit angeben sind (C#: virtual). (Wir kommen weiter unten auf diese besondere Form der Klassen zurück.) Die Basis-Klasse Fernseher hat mehrere abgeleitete Klassen: CRT-, LCD- und Plasmafernseher (letzterer ist nicht dargestellt). Aus diesen lassen sich weitere Klassen ableiten. Zum Beispiel LCD 50 Hz und LCD 100 Hz Fernseher. Aber immer erben die abgeleiteten Klassen die Eigenschaften und Methoden der Basis-Klassen. Mehr noch: Ein Objekt aus der abgeleiteten Klasse enthält immer auch ein Objekt aus der Basisklasse - sofern die Basisklasse weder eine abstrakte noch eine statische Klasse ist! Denn von diesen beiden kann man, wie wir später sehen werden, keine realen Objekte instantiieren! In UMLed wird übrigens nicht zwischen Eigenschaften und Methoden unterschieden. Allerdings kann man bei der Erzeugung eines Attributs gleich eine Schreib- und/oder Leseeigenschaft miterzeugen. 448

Der etwas merkwürdige, aber gebräuchliche Satz: Ein Objekt wird instantiiert bedeutet, dass im Heap (= bestimmter Bereich des RAM) nach Vorgabe der Klassendefinition konkrete Werte in die vorher undefinierten Speicherinhalte geschrieben werden. Stellen Sie sich die Klassendefinition wie einen Stempel vor, der bei jedem neu zu bildenden Objekt seinen Abdruck im Heap hinterlässt. Dieser Abdruck beeinhaltet den Speicherbedarf. Bei jedem neu zu erstellenden Objekt wird wieder gestempelt! Jedes Objekt hat auf diese Weise seinen eigenen Speicherinhalt. In den Speicher werden dann zum Beispiel die Inhalte der Felder eingetragen. Erst dadurch können konkrete Berechnungen mit dem Objekt durchgeführt werden. Unsere Kasse Fernseher ist in diesem Sinn eine abstrakte Klasse, weil sich in den Bauplänen für Fernseher lediglich der Name für die Methode Helligkeit ändern vermerkt ist. Alles andere wäre ja auch Unsinn, denn erst in den abgeleiteten Klassen, wie CRT-Fernseher, kann ein konkreter Bauplan für diese Methode angegeben werden, denn dieser dürfte ja beispielsweise bei der Klasse LCD- Fernseher völlig anders aussehen! Klassen beschreiben also die gemeinsamen Eigenschaften und Methoden einer Menge von gleichartigen Objekten. Durch die Klassendefinition werden Vorlagen (Stempel!) für die nötigen Speicherreservierungen der zu erzeugenden Objekte erstellt. 449

Objekte sind also die konkreten erzeugten Exemplare einer Klasse. In unserem Beispiel ist also der reale, mit Händen zu greifende CRT-Fernseher, 40 Zoll ein Objekt der Klasse CRT-Fernseher. Es kann viele verschiedene Objekte einer Klasse geben. Sie haben gerade eben erfahren, dass ein Objekt Platz im Speicher benötigt. Diesen Platz besorgt der Konstruktor der Klasse. Wird das Objekt nicht mehr benötigt, sorgt der Destruktor dafür, dass der Platz wieder freigegeben wird. Verwendet man als Programmiersprache C#, so hat man mit den beiden nicht viel zu tun. Der Garbage Collector sorgt von Zeit zu Zeit automatisch dafür, dass nicht mehr benötigte Exemplare gelöscht werden. Ruft man in C# keinen Konstrukor auf, so wird bei der Bildung eines Exemplars automatisch ein Standard-Konstruktor aufgerufen. Will man allerdings bei der Erzeugung des Objekts einige Eigenschaften initialisieren, so überschreibt (siehe nächster Abschnitt) man den Standard-Konstruktor. Damit Sie nicht vor lauter neuen Begriffen den Überblick verlieren, wollen wir mit Hilfe der UML etwas mehr Anschauung ins Spiel bringen. Wir verwenden das schon oben erwähnte Programm UMLed. Damit kann man anschaulich Klassen und ihre Beziehungen darstellen (siehe UML-Bild oben). Das Programm kann allerdings noch mehr: Hat man eine korrekte Klasse als Diagramm erstellt, so bekommt man den dazugehörigen Quelltext für diese Klasse. (In Delphi oder in Java!) Der Programmcode von C# ähnelt sehr stark dem Java-Code. Daher nutzen wir die den Export. Das obige Beispiel sieht in Java so aus: /** * import-liste * ggf. weiter von Hand anpassen */ public abstract class Fernseher { /** * Attribute der Klasse */ public int Bildschirmdiagonale; protected int Kanal; private int Helligkeit; private int Lautstaerke; 450

/** * Attribute die aus Beziehungen resultieren */ /** * Fernseher: Methoden */ /********* Fernseher (public) ******************************************/ public Fernseher(int Bildschirmdiagonale) { //hier ggf. Code ergänzen } /********* SetzeHelligkeit (public) ************************************/ public void SetzeHelligkeit(int phelligkeit) { Helligkeit = phelligkeit } /********* SetzeKanal (public) *****************************************/ public void SetzeKanal(int pkanal) { Kanal = pkanal } /********* SetzeLautstaerke (public) ***********************************/ public void SetzeLautstaerke(int plautstaerke) { Lautstaerke = plautstaerke } /********* GibHelligkeit (public) **************************************/ public int GibHelligkeit() { return Helligkeit } /********* GibKanal (public) *******************************************/ public int GibKanal() { return Kanal } /********* GibLautstaerke (public) *************************************/ public int GibLautstaerke() { return Lautstaerke } } Die braunen Textstellen sind lediglich Kommentare! Man spart also kaum Schreibarbeit. Der Vorteil solcher UML-Programme liegt in der besseren Übersicht durch die grafische Darstellung. Wenn Sie sich in Kapitel 1 mit OOP in C# beschäftigen werden, sehen Sie, dass die Unterschiede zwischen Java und C# minimal sind. 451

Man kann im obigen Programmfragment auch gut erkennen, dass die Zugriffsmodifizierer private, protected oder public gewählt wurden. Damit legt man die Stärke der Einschränkung, wie auf die Methoden zugegriffen werden darf fest: private : Nur von dieser Klasse aus protectet: Von allen abgeleiteten Klassen aus public: Von überall. Im Fenster rechts können Sie im Programm UMLed diese Zugriffsbeschränkungen einstellen. Den Pfeil von CRT-Fernseher zu Fernseher kann man unter unter dem Menupunkt Beziehungen hinzufügen. In diesem Fall ist es eine IST-Beziehung: Der CRT-Fernseher ist ein Fernseher. Somit erbt er alle Felder und Methoden von der Klasse Fernseher. Um den Pfeil im Diagramm unterzubringen ist etwas Übung nötig: Man muss nach der Wahl der Beziehung IST auf einen Markierungspunkt der Klasse treffen, auf der der Pfeil landen soll. Danach klickt man auf die Klasse, von der der Pfeil startet. Für die Fernbedienung im UML-Bild passt die IST-Beziehung nicht. Was soll eine Fernbedienung auch von einem Fernseher erben?! Man spricht in diesem Fall von einer HAT-Beziehung. Ein Fernseher hat eine Fernbedienung. 452

Aufgabe 3 Laden Sie sich aus dem Tauschverzeichnis das UMLed-Projekt Fernseher03.urd und öffnen Sie es mit dem Programm. Ergänzen Sie nun das Diagramm durch Hinzunahme der Klassen CRT-50Hz-Fernseher und LCD-100HZ-Fernseher. Lassen Sie sich den Delphicode dazu anzeigen. (Siehe Bild rechts!) Konstruieren Sie mit dem Programm ein Klassendiagramm für die Klassen Viereck, Rechteck und Quadrat. Wie würden Sie in diesem Diagramm die Klasse Trapez unterbringen? Vererbung und Polymorphie Der Begriff der Vererbung ist ein solch wesentlicher Begriff der OOP, dass er einen eigenen Abschnitt bekommt. Verstanden haben sollten Sie bis hier her folgendes: 1. Die Klasse CRT-Fernseher 100 Hz erbt von der Klasse CRT-Fernseher alle Felder und Methoden. 2. In der Klasse CRT-Fernseher 100 Hz kann man weitere Felder und Methoden deklarieren, die dann aber CRT-Fernseher nicht kennt. 3. Es muss geklärt werden, was passiert, wenn in der abgeleiteten Klasse namensgleiche Felder oder Methoden definiert werden, wie sie in der Basisklasse bereits vorhanden sind. In der Analogie: Was passiert, wenn in der Klasse CRT-Fernseher 100 Hz eine eigene Methode Helligkeit ändern formuliert und aufgerufen wird? Damit die Vererbung problemlos klappt, muss, wie oben schon angedeutet, die sogenannte IST ein/e -Bedingung gelten: CRT-Fernseher ist ein Fernseher. In diesem Sinne ist ein LCD-Fernseher kein CRT-Fernseher, kann ihn also auch nicht beerben. Was man benötigt, damit die beiden Exemplare doch etwas miteinander zutun haben, ist Ihnen klar: Eine Basisklasse Fernseher! Diese Klasse selbst ist abgeleitete Klasse der Klasse Elektrische Multimediageräte. Diese wiederum ist abgeleitet von der Klasse Elektrogeräte Die Klasse CRT-Fernseher 100 Hz verfügt daher über alle Felder und Methoden der Klasse Elektrogeräte. Nun, - sehr viele werden das nicht sein! Fallen Ihnen welche ein? Kommen wir zum dritten Punkt, der Klärung der Frage, was passiert, wenn es namensgleiche Eigenschaften oder Methoden in der Basis- wie in der abegleiteten Klasse gibt?. Dazu bemühen wir wieder die Analogie: 453

Entwickler haben bei der Klasse CRT-Fernseher 100 Hz ein neues und besseres Verfahren entwickelt, wie man die Helligkeit des Bildes verändern kann. Nun hat die Klasse ja schon eine Methode Helligkeit verändern geerbt. Prinzipiell gibt es nun mehrere Möglichkeiten für die Entwickler: Sie benennen die neue Methode um, - bauen also zwei Knöpfe an den Apparat, mit denen man die Helligkeit beeinflussen kann. Sie bleiben beim Namen, verstecken den zweiten Knopf (die alte Methode) aber im Gehäuse. Sie bleiben beim Namen und überschreiben die alte Methode, will heißen, sie nehmen kleinere Veränderungen dort vor. Dies ist jedoch nur möglich, wenn die alte Methode dafür vorgesehen ist. Ob die Methode dafür vorgesehen ist oder nicht, erkennt man an dem aufgedruckten Wort virtual. Allerdings müssen Sie die überschriebene Methode dann durch das Wort override kennzeichnen. Die ersten beiden Verfahren sind nicht besonders sinnvoll. Das bedeutet, dass man bei der Konstuktion der Klassen darauf achten muss, dass Methoden, die in abgeleiteten Klassen möglicherweise modifiert werden sollen, in der Basisklasse als virtual deklariert werden sollten. Wenn eine Methode überschrieben wurde, so sagt man auch, die Methode ist überlagert. Der Compiler ist in der Lage, zu erkennen, welche der überlagerten Methoden bei einem Aufruf zu verwenden ist, denn selbst beim Überschreiben bleibt die alte Methode aus der Basisklasse vorhanden und wird somit automatisch dann verwendet, wenn das aufrufende Objekt aus der Basisklasse kommt. Achtung, - nicht verwechseln: Überladen heißt eine Methode hingegen, wenn es eine namensgleiche Methode in der Klasse gibt, die aber andere Parameter entgegennimmt. Wir sollten noch die Frage klären, ob es sinnvoll ist, ob beispielsweise ein Objekt aus der abgeleiteten Klasse (mittels einer eigenen Methode) den Inhalt eines Feldes aus der Basisklasse ändern darf. Wie wir schon erkannt haben, wird der Zugriff auf Felder und Methoden durch die sogenannten Zugriffsmodifizierer geregelt. Mittels public bespielsweise kann man von überall aus auf die Felder dieser Klasse zugreifen und somit Änderungen vornehmen. Verwendet man hingegen private, so ist mit eigenen Methoden der abgeleiteten Klasse nichts zu machen. Und das ist ja auch gut so! Gibt es Situationen, in denen wir den Methoden der abgeleiteten Klassen (und nur diesen) einen exklusiven Zugang zu den Eigenschaften der Basisklasse erlauben sollten? Zurück zu unsere Analogie: Basisklasse sei CRT-Fernseher. Abgeleitete Klasse CRT-Fernseher 100 HZ. ( Die 100 Hz-Technologie wurde entwickelt, damit das Bild weniger flackert. ) Nun haben die Entwickler diesem 100 Hz-Fernseher eine Taste auf der Fernbedienung spendiert, mit der man das Bild für Filme optimieren kann. (Es werden dann bestimmte Werte für Helligkeit, Kontrast, Farbsättigung etc. eingestellt.) 454

Diese Methode Bild optimieren hat die Basisklasse CRT-Fernseher nicht. Wären die Eigenschaften Helligkeit, Kontrast und Farbsättigung jetzt private, dann könnte die Methode Bild optimieren (der abgeleiteten Klasse) nichts an diesen Werten ändern und die Taste funktioniert nicht. Für solche Fälle hat man den Klassen einen weiteren Zugriffsmodifizierer zur Verfügung gestellt: protected. Er erlaubt den Zugriff zu diesen Eigenschaften und Methoden nur den daraus abgeleiteten Klassen. Bleibt zu klären, was man in der OOP unter Polymorphie versteht. Wie oben: Basisklasse ist CRT-Fernseher. Abgeleitete Klasse CRT-Fernseher 100 HZ. Daraus wiederum wird die Klasse CRT-Fernseher 100 Hz Flatscreen abgeleitet. Alle haben die Methode Helligkeit ändern. Nehmen wir an, dass in den beiden abgeleiteten Klassen die Methode überschrieben wurde. Vermutlich haben die Entwickler im Laufe der Zeit immer bessere Methoden entwickelt. Aber: Leider funktioniern die Helligkeit ändern -Methoden der abgeleiteten Klassen nicht in den Basisklassen wie gewünscht. Das heißt: Eine Kontrollinstanz (Compiler) muss wissen, welche Methode denn nun bei einem bestimmten Fernseher (Objekt) anzuwenden ist. Und das war s schon: Diese Fähigkeit nennt man Polymorphie. Nicht alle Programmiersprachen sind polymorph. Viele Programmiersprachen wie z.b. Pascal und Basic verlangen, dass für jede Art von Listen eine Methode speziell für diese Art von Eigenschaften programmiert wird. Nichtpolymorphe Programmiersprachen haben die folgenden Nachteile: 1. Die Nichtpolymorphie vergrößert unnötig die Programme und trägt dazu bei, sie unübersichtlich zu machen. 2. Die Nichtpolymorphie erschwert die Wartung von Programmen, weil derselbe Algorithmus in verschiedenen Prozeduren verbessert werden muss. Die Polymorphie stellt also eine Abstraktion dar, die in Programmiersprachen äußerst wünschenswert ist. Vielleicht denken Sie jetzt, dass das Überladen einer Methode ja auch eine Art der Polymorphie ist. Sie haben recht: Man nennt es daher auch: parametrische Polymorphie. 455

Aufgabe 4 Wie Sie zweifellos bemerkt haben, wurde in diesem Kapitel 5.01, beinahe losgelöst von jeder konkreten Programmiersprache, eine Theorie über die Anforderungen an eine solche Sprache dargelegt. Stellen Sie sich nun vor, Sie wollen einem Freund, der bisher nur in Basic, C oder Pascal (strukuriert!) programmiert hat, eine kurze Erklärung geben, was man unter OOP versteht. Führen Sie diese Aufgabe in Partnerarbeit durch. Einer übernimmt den Part des Erklärenden, der Andere den des ahnungslosen Zuhörers. Am Ende wird der Zuhörer zum Kritiker und stellt nun seine Sicht der Dinge dar. Für den Fall, dass Sie unsicher sind schauen Sie im Skript nach oder schauen hier: http://www.oszhandel.de/gymnasium/faecher/informatik/recht/xgym/oop_1.0.htm Was die Sache am Anfang so schwierig macht, sind die Fülle der neuen Begriffe und natürlich auch der relativ hohe Abstrakionsgrad. Aus diesem Grund werden Sie nun selbst erste Erfahrungen mit der OOP machen. Und zwar auf einem Gebiet, dass Ihnen von der Unterstufe an vertraut sein sollte: Der Geometrie. Die Fachbereiche Mathematik und Dikaktik der Universität Bayreuth haben schon vor einigen Jahren ein auf Java laufendes Programm namens GEONExT entwickelt. Das Programm kann hier (inklusive der Java-Umgebung) runtergeladen werden: http://geonext.uni-bayreuth.de/index.php?id=2277 (Sie können es auch aus dem Tauschverzeichnis laden). Allerdings ist es auch auf einem Browser ohne vorherige Installation lauffähig, sofern man eine aktuelle Java Laufzeitumgebung installiert hat. Im folgenden Bild ist das Fenster des Programms zu sehen. 456

Natürlich wollen wir hier keine Geometrie machen. Wir wollen der OOP auf die Spur kommen. Und genau zu diesem Zweck wurde ebenfalls an diesem Lehrstuhl ein Tutorial für OOP auf der Basis von GEONExT entwickelt. Wie Sie unten sehen können, sind hierfür 8 Stationen zu durch laufen. Beachten Sie bitte, dass in GEONExT Felder Attribute genannt werden! Attributwerte sind dann natürlich (Daten-) Inhalte der Felder. Aufgabe 5 Laden Sie sich das Tutorial aus dem Tauschverzeichnis in das Homeverzeichnis. Doppelklicken Sie die Datei start.htm. Der Zeitbedarf für das gesamte Tutorial beträgt ca. 2 Stunden. Die Stationen 1 und 2 erkunden Sie alleine. Für die Stationen 3 bis 5 arbeiten Sie mit einem Partner. Station 6 ist Hausaufgabe. Auch wenn Ihnen nach der obigen Aufgabe nun doch einiges klarer geworden ist, sollen Sie beachten, dass das vorliegende Kapitel 5.01 ist insbesondere auch dafür gedacht ist, dass Sie, wenn es nachher ans konkrete Programmieren geht, bei Unsicherheit bezüglich eines bestimmten Begriffs der OOP, hier nachsehen können! 457