Klassen, Vererbung und UML

Klasse, Objekt und UML-Klassendiagramm

Eine Klasse ist ein Bauplan. Sie legt fest, welche Daten (Attribute) und welches Verhalten (Methoden) ihre Exemplare haben. Ein Objekt ist ein konkretes Exemplar einer Klasse mit eigenen Attributwerten. Die Klasse Fahrrad gibt es einmal, Objekte davon beliebig viele.

Das UML-Klassendiagramm zeichnet eine Klasse als Rechteck mit drei Abschnitten: Klassenname, Attribute, Methoden. Attribute stehen als name: Typ, Methoden als name(parameter: Typ): Rückgabetyp. Das Zeichen vor dem Namen gibt die Sichtbarkeit an: - für private, + für public.

In Java sieht die Klasse so aus. Der Konstruktor trägt den Klassennamen, hat keinen Rückgabetyp und setzt den Anfangszustand. Mit this ist das eigene Objekt gemeint.

public class Fahrrad {

    private String farbe;

    private int gaenge;

    public Fahrrad(String farbe, int gaenge) {

        this.farbe = farbe;

        this.gaenge = gaenge;

    }

    public void schalte(int g) {

        gaenge = g;

    }

}

// Objekt erzeugen:

Fahrrad meinRad = new Fahrrad("rot", 21);

Kapselung und Sichtbarkeit

Wäre gaenge öffentlich, könnte jeder Code meinRad.gaenge = -5; schreiben. Das Objekt hätte dann einen unsinnigen Zustand. Deshalb gilt das Geheimnisprinzip (Kapselung): Attribute sind private, der Zugriff läuft über öffentliche Methoden, die Werte prüfen können.

Lesender Zugriff erfolgt über einen Getter (getStand()), schreibender über einen Setter oder eine fachlich benannte Methode wie einzahlen.

public class Konto {

    private double stand;

    public double getStand() { return stand; }

}

Vererbung

Hund und Katze haben beide einen Namen und ein Alter, nur Bellen und Miauen unterscheiden sie. Was alle gemeinsam haben, steht einmal in der Oberklasse Tier. Die Unterklassen Hund und Katze erben es und ergänzen oder ändern nur das Besondere. Es gilt die ist-ein-Beziehung: Ein Hund ist ein Tier.

In UML zeigt ein Pfeil mit unausgefülltem Dreieck von der Unterklasse zur Oberklasse. Attribute, die Unterklassen direkt nutzen sollen, werden protected (UML: #). Sie stehen nur in der Oberklasse.

In Java steht extends. Der Konstruktor der Unterklasse ruft zuerst mit super(...) den Konstruktor der Oberklasse auf:

public class Medium {

    protected String titel;

    protected String signatur;

    public Medium(String titel, String signatur) {

        this.titel = titel;

        this.signatur = signatur;

    }

}

public class Buch extends Medium {

    private int seitenzahl;

    public Buch(String titel, String signatur, int seitenzahl) {

        super(titel, signatur);   // muss die erste Anweisung sein

        this.seitenzahl = seitenzahl;

    }

}

Abstrakte Klassen und Polymorphie

Zurück zur Verkehrssimulation: Jedes Fahrzeug muss sich bewegen, aber wie, hängt vom Typ ab. In Fahrzeug lässt sich bewege() nicht sinnvoll ausprogrammieren. Man deklariert die Methode daher abstrakt: Sie hat nur einen Kopf, keinen Rumpf. Eine Klasse mit abstrakten Methoden muss als abstract deklariert werden, und von einer abstrakten Klasse kann man keine Objekte erzeugen, denn ein Objekt müsste jede Methode ausführen können.

abstract class Form {

    abstract double flaeche();      // kein Rumpf

}

class Kreis extends Form {

    double r;

    Kreis(double r) { this.r = r; }

    double flaeche() { return Math.PI * r * r; }

}

new Form() ist deshalb ein Übersetzungsfehler. Jede nicht abstrakte Unterklasse muss die abstrakten Methoden überschreiben (UML: Klassenname und abstrakte Methoden kursiv).

Polymorphie (Vielgestaltigkeit): Eine Variable vom Typ der Oberklasse darf auf Objekte jeder Unterklasse zeigen. Welche Methode läuft, entscheidet erst zur Laufzeit der tatsächliche Objekttyp. Das heißt dynamisches Binden.

Entscheidend ist die Frage, welche Methode aufgerufen wird. Im Beispiel unten ruft hallo() (in A) die Methode wer() auf:

class A { String wer(){ return "A"; }

          String hallo(){ return "Hallo " + wer(); } }

class B extends A { String wer(){ return "B"; } }

// A x = new B(); System.out.println(x.hallo());

Obwohl hallo() in A steht, läuft wer() aus B, denn das Objekt ist ein B. Ausgabe: Hallo B. Wäre wer() in A dagegen private, ist die Methode in Unterklassen nicht sichtbar, B.wer() ist dann eine ganz neue Methode und keine Überschreibung. Der Aufruf in hallo() bleibt bei A.wer(), die Ausgabe lautet daher Hallo A.

abstract class Form { abstract double flaeche(); }

class Kreis extends Form {

    double r;

    Kreis(double r){ this.r = r; }

    double flaeche(){ return Math.PI * r * r; }

}

class Quadrat extends Form {

    double a;

    Quadrat(double a){ this.a = a; }

    double flaeche(){ return a * a; }

}

class A { String wer(){ return "A"; } String hallo(){ return "Hallo " + wer(); } }

class B extends A { String wer(){ return "B"; } }

Assoziationen und Multiplizitäten

Nicht jede Beziehung ist Vererbung. Ein Kurs hat einen Lehrer und hat Schüler. Das ist eine Assoziation, in UML eine einfache Linie. An den Enden stehen die Multiplizitäten: wie viele Objekte der einen Seite zu einem Objekt der anderen gehören. Typisch sind 1, 0..1, * (beliebig viele) und 1..*.

Die Zahl neben einer Klasse sagt, wie viele Objekte dieser Klasse zu einem Objekt der anderen Klasse gehören: Zu einem Kurs gehört genau ein Lehrer (1 neben Lehrer), zu einem Kurs gehören viele Schüler (* neben Schueler). Neben Kurs steht im Diagramm keine Multiplizität, weil hier nur diese beiden Aussagen über den Kurs gemacht werden.

Umsetzung in Java: Eine Assoziation wird zu einem Attribut der Klasse, die die andere „kennt“. Die Multiplizität 1 wird eine einzelne Referenz, * eine Sammlung (Feld oder ArrayList):

public class Kurs {

    private Lehrer lehrer;                       // Multiplizität 1

    private ArrayList<Schueler> schueler;        // Multiplizität *

    public Kurs(Lehrer lehrer) {

        this.lehrer = lehrer;

        this.schueler = new ArrayList<Schueler>();

    }

}

Klassenbibliotheken und systematisches Testen

Niemand programmiert Listen oder Sortierverfahren jedes Mal neu. Eine Klassenbibliothek bietet fertige, getestete Klassen. Die ArrayList<T> aus java.util verwaltet eine veränderliche Folge von Objekten des Typs T:

Vorteile der Wiederverwendung: weniger Entwicklungszeit, geprüfte Qualität, einheitliche Schnittstelle (andere Entwickler kennen sie), Pflege durch Dritte. Nachteile: Abhängigkeit, Einarbeitung, eventuell mehr Funktionalität als nötig.

Systematisch testen heißt, Testfälle nach einem Plan zu wählen, nicht beliebig. Bilden Sie Äquivalenzklassen (Eingaben, bei denen sich das Programm gleich verhält) und testen Sie zusätzlich die Grenzfälle. Zu jedem Testfall gehört das vorher festgelegte erwartete Ergebnis.

Zurück zur Verkehrssimulation: Mit einer abstrakten Oberklasse Fahrzeug, privaten Attributen mit Gettern und einer Methode bewege() pro Unterklasse bleibt die Hauptschleife unverändert, wenn neue Fahrzeugtypen dazukommen. Der Bus erhält wie der Transporter oben zusätzlich eine Liste seiner Haltestellen. Die privaten Attribute verhindern, dass anderer Code etwa die Geschwindigkeit auf einen unsinnigen Wert setzt.

Auf einen Blick

• Klasse = Bauplan (Attribute, Methoden), Objekt = Exemplar mit eigenem Zustand. UML: Rechteck mit drei Abschnitten, - für private, + für public.

• Kapselung: Attribute private, Zugriff über Methoden, die Werte prüfen können.

• Vererbung (extends, ist-ein, super(...) im Konstruktor): Gemeinsames steht einmal in der Oberklasse. UML-Pfeil mit offenem Dreieck.

• Abstrakte Klasse: mindestens eine Methode ohne Rumpf, keine Objekte erzeugbar. Unterklassen müssen die Methoden implementieren.

• Polymorphie / dynamisches Binden: Der Objekttyp entscheidet zur Laufzeit, welche überschriebene Methode läuft. private Methoden werden nicht überschrieben.

• Assoziation („hat ein“) wird in Java ein Attribut: Multiplizität 1 → Referenz, * → ArrayList oder Feld.

• Klassenbibliotheken wie ArrayList sparen Aufwand. Testen mit Äquivalenzklassen, Grenzfällen und vorab berechneten Sollwerten.

• Operatoren: erläutern Sie Begriffe an Beispielen, entwerfen Sie Diagramme, begründen Sie Entwurfsentscheidungen, beurteilen Sie Nutzen und Grenzen.