Objektorientierung: Kapselung, Vererbung, Polymorphie

Ein Zeichenprogramm kennt Kreise, Rechtecke und Dreiecke. Nun soll ein Fünfeck dazukommen.

In einem Programm ohne Objektorientierung muss man dafür jede Stelle suchen, an der Formen behandelt werden, und überall einen Fall ergänzen. Vergisst man eine, entsteht ein Fehler, der oft erst viel später auffällt.

Mit Objektorientierung schreibt man eine neue Klasse und ändert am bestehenden Code keine Zeile. Wie das möglich ist, ist der Inhalt dieses Kapitels. Der Schlüssel heißt Polymorphie, und er ist der eigentliche Gewinn des ganzen Ansatzes.

Vorausgesetzt werden Klasse, Objekt, Attribut, Methode und das Klassendiagramm aus Objektorientierte Modellierung.

Neu sind hier die drei Mittel, die aus der Modellierung eine tragfähige Bauweise für große Programme machen: Kapselung, Vererbung und Polymorphie.

Eine Klasse legt fest, welche ihrer Bestandteile von außen erreichbar sind:

Üblich ist: Attribute privat, Methoden öffentlich. Der Zugriff läuft über Methoden.

Warum dieser Umweg? Sieh dir den Unterschied an:

konto.kontostand = -5000        // direkt: nichts prüft etwas

konto.abheben(5000)             // über Methode: die Klasse prüft

Im ersten Fall kann jede Stelle des Programms jeden Wert setzen, auch einen unsinnigen. Im zweiten entscheidet die Klasse selbst, ob der Vorgang zulässig ist.

🔴 Der eigentliche Gewinn liegt tiefer, als „vor Fehlern schützen". Die Klasse gibt eine Zusage nach außen: Der Kontostand unterschreitet nie den Verfügungsrahmen. Solange alle Zugriffe über Methoden laufen, gilt diese Zusage immer, ohne dass irgendjemand außerhalb darauf achten muss. Man muss den Rest des Programms nicht kennen, um sicher zu sein.

Das ist derselbe Gedanke wie beim abstrakten Datentyp: außen die zugesagten Operationen, innen die frei wählbare Umsetzung. Wechselt man später die interne Speicherung, bleibt der benutzende Code unverändert.

Oft sind mehrere Klassen einander ähnlich. Ein Schüler und ein Lehrer haben beide Name und Geburtsdatum, unterscheiden sich aber in anderem.

Die Vererbung zieht das Gemeinsame in eine Oberklasse; die Unterklassen übernehmen es und ergänzen ihr Eigenes.

        ┌─────────────────┐
        │     Person      │
        │ - name          │
        │ - geburtsdatum  │
        │ + alter()       │
        └────────△────────┘
                 │
       ┌─────────┴─────────┐
┌──────┴──────┐    ┌───────┴──────┐
│   Schüler   │    │    Lehrer    │
│ - klasse    │    │ - faecher    │
│ + zeugnis() │    │ + stundenplan()│
└─────────────┘    └──────────────┘

Das Dreieck zeigt zur Oberklasse. Ein Objekt der Klasse Schüler hat damit $\texttt{name}$, $\texttt{geburtsdatum}$, $\texttt{alter()}$, $\texttt{klasse}$ und $\texttt{zeugnis()}$.

Die Prüffrage für jede Vererbung lautet: „Ist ein Schüler eine Person?" Ja. Dann ist Vererbung richtig.

Eine Unterklasse darf eine geerbte Methode ersetzen. Das nennt man Überschreiben.

Klasse Form:
    flaeche():  gib 0 zurück

Klasse Kreis erbt von Form:
    flaeche():  gib 3.14159 * radius * radius     // überschreibt

Klasse Rechteck erbt von Form:
    flaeche():  gib laenge * breite               // überschreibt

Wichtig ist der Unterschied zum Überladen: Überschreiben ersetzt eine geerbte Methode gleichen Namens und gleicher Parameter in der Unterklasse. Überladen bedeutet, mehrere Methoden gleichen Namens mit verschiedenen Parametern in derselben Klasse anzubieten. Das eine hat mit Vererbung zu tun, das andere nicht.

Jetzt der entscheidende Punkt des Kapitels.

Polymorphie heißt: Ein Objekt einer Unterklasse darf überall dort stehen, wo die Oberklasse erwartet wird, und beim Aufruf einer überschriebenen Methode wird die Fassung der tatsächlichen Klasse ausgeführt.

formen = [ Kreis(5), Rechteck(3,4), Kreis(2) ]

für jede f in formen:
    ausgeben(f.flaeche())

Die Schleife weiß nicht, welche Form sie gerade vor sich hat. Sie ruft $\texttt{flaeche()}$ auf, und jedes Objekt antwortet mit seiner eigenen Berechnung.

🔴 Der Gewinn zeigt sich beim Erweitern. Kommt ein Dreieck dazu, schreibt man:

Klasse Dreieck erbt von Form:
    flaeche():  gib 0.5 * grundseite * hoehe

Und ändert an der Schleife keine Zeile. Der bestehende Code funktioniert weiter, weil er nie nach der konkreten Klasse gefragt hat.

Vergleiche das mit der Alternative ohne Polymorphie:

für jede f in formen:
    wenn f ist Kreis:       ausgeben(kreisflaeche(f))
    sonst wenn f ist Rechteck: ausgeben(rechteckflaeche(f))
    sonst wenn f ist Dreieck:  ausgeben(dreiecksflaeche(f))
    ...

Diese Fallunterscheidung steht erfahrungsgemäß nicht an einer Stelle, sondern an einem Dutzend: beim Zeichnen, beim Speichern, beim Berechnen des Umfangs. Jede neue Form verlangt eine Ergänzung an jeder dieser Stellen, und jede vergessene ist ein Fehler.

Man kann den Nutzen in einem Satz fassen: Polymorphie ersetzt Fallunterscheidungen über den Typ durch die Wahl der Klasse. Statt zu fragen „was bist du?", sagt man „tu, was du kannst".

Bei $\texttt{Form}$ fällt etwas auf: Was soll $\texttt{flaeche()}$ dort eigentlich zurückgeben? Die 0 oben ist ein Notbehelf, denn eine „Form" ohne nähere Angabe hat keine Fläche.

Eine abstrakte Klasse löst das. Sie schreibt vor, dass jede Unterklasse eine bestimmte Methode besitzen muss, gibt aber selbst keine Umsetzung an, und von ihr lassen sich keine Objekte erzeugen.

abstrakte Klasse Form:
    abstrakt flaeche()          // keine Umsetzung, Pflicht für Unterklassen
    beschreibung():             // normale geerbte Methode
        gib "Fläche: " + flaeche()

Das ist mehr als Kosmetik: Eine Unterklasse, die $\texttt{flaeche()}$ vergisst, wird schon vom Übersetzer beanstandet, statt später eine sinnlose 0 zu liefern.

Der häufigste Entwurfsfehler ist Vererbung an der falschen Stelle. Die Unterscheidung ist einfach:

Ein Auto ist kein Motor, also darf $\texttt{Auto}$ nicht von $\texttt{Motor}$ erben. Stattdessen bekommt $\texttt{Auto}$ ein Attribut vom Typ $\texttt{Motor}$; das nennt man Komposition.

Ein verbreiteter Fehlgriff ist auch $\texttt{Quadrat}$ erbt von $\texttt{Rechteck}$. Geometrisch stimmt es, und trotzdem geht es schief: Ein Rechteck erlaubt, Länge und Breite unabhängig zu setzen, ein Quadrat nicht. Die Unterklasse kann die Zusagen der Oberklasse also nicht einhalten. Die Prüfung „ist ein" allein reicht deshalb nicht; man muss zusätzlich fragen, ob die Unterklasse überall dort einsetzbar ist, wo die Oberklasse steht.

Die Reihenfolge ist keine Rangfolge, aber die dritte Zeile ist der Grund, aus dem sich der Ansatz durchgesetzt hat.