Konstruktoren + Sichtbarkeit (public / private)

Du schreibst new Student("Müller", 1001), was passiert in dieser einen Zeile? Java reserviert Speicher im Heap, ruft den Konstruktor auf, und der setzt die Felder. Aber WIE? Was passiert wenn du keinen Konstruktor definierst? Wieso darf man manche Felder nur über Methoden setzen? Genau das beantwortet dieses Topic. Klausur-Pflicht in 13/17 WInf-Prog-1-Klausuren.

Du lernst hier den Default-Konstruktor, eigene Konstruktoren mit Überladung, das Verketten über this(...) und super(...), die Reihenfolge der Feld-Initialisierung sowie die vier Sichtbarkeitsstufen (public, protected, package-private, private) und warum Encapsulation Felder vor unkontrolliertem Zugriff schützt.

Die Idee in einem Satz

Konstruktor: Spezieller Code-Block mit dem Namen der Klasse, technisch keine normale Methode (kein Rückgabetyp, nicht vererbt), der beim new aufgerufen wird und das frisch erzeugte Objekt initialisiert. Sichtbarkeit regelt, wer von außen auf Felder/Methoden zugreifen darf.

Standard-Konstruktor (Default Constructor)

Wenn du keinen Konstruktor definierst, gibt Java dir einen kostenlos: parameterlos, leer.

public class Student {
    String name;
    int matrnr;
}

// kompiliert, weil Java automatisch einen Konstruktor anlegt:
// public Student() {}

Student s = new Student();  // name = null, matrnr = 0
s.name = "Müller";
s.matrnr = 1001;

Aber: sobald du selbst einen Konstruktor schreibst, ist der Default-Konstruktor weg. Klausur-Klassiker:

public class Student {
    String name;
    int matrnr;

    public Student(String name, int matrnr) {  // eigener Konstruktor
        this.name = name;
        this.matrnr = matrnr;
    }
}

Student s = new Student();  // FEHLER, kein parameterloser Konstruktor mehr!

Eigene Konstruktoren

Konstruktor heißt genauso wie die Klasse, hat keinen Rückgabetyp (nicht mal void).

public class Student {
    String name;
    int matrnr;
    int semester;

    public Student(String name, int matrnr) {
        this.name = name;
        this.matrnr = matrnr;
        this.semester = 1;  // Default
    }
}

Das this.name = name löst den klassischen Namens-Konflikt: Parameter heißt name, Feld heißt auch name. this.name ist das Feld, name allein der Parameter. Ohne this würde name = name nur den Parameter auf sich selbst setzen, das Feld bliebe unverändert.

Konstruktor-Überladung

Mehrere Konstruktoren mit unterschiedlichen Parametern, Java wählt automatisch den passenden.

public class Student {
    String name;
    int matrnr;
    int semester;

    public Student(String name, int matrnr) {
        this(name, matrnr, 1);  // ruft anderen Konstruktor (Constructor Chaining)
    }

    public Student(String name, int matrnr, int semester) {
        this.name = name;
        this.matrnr = matrnr;
        this.semester = semester;
    }
}

Student s1 = new Student("Müller", 1001);              // Semester wird 1
Student s2 = new Student("Schulz", 1002, 5);           // Semester = 5

this(...) ruft einen anderen Konstruktor derselben Klasse auf. Muss die ERSTE Zeile im Konstruktor sein.

super(): der Konstruktor der Oberklasse

Bei Vererbung ruft jeder Konstruktor zuerst den Konstruktor der Oberklasse auf, explizit mit super(...) oder implizit mit super().

public class Person {
    String name;
    public Person(String name) { this.name = name; }
}

public class Student extends Person {
    int matrnr;
    public Student(String name, int matrnr) {
        super(name);        // ruft Person(String) auf, MUSS erste Zeile sein
        this.matrnr = matrnr;
    }
}

Schreibst du kein super(...), fügt Java automatisch super() (parameterlos) als erste Zeile ein. Hat die Oberklasse keinen parameterlosen Konstruktor, ist das ein Compile-Error: dann musst du super(...) explizit mit Argumenten aufrufen. super(...) und this(...) schließen sich aus, pro Konstruktor nur eines, immer als erste Zeile.

Reihenfolge der Initialisierung

Bei new Student("Müller", 1001) läuft es von oben nach unten durch die Vererbungskette:

1. Heap-Speicher reservieren, alle Felder auf Default (null / 0 / false)
2. super(...): Konstruktor der Oberklasse (Person) komplett ausführen
3. Feld-Initializer der eigenen Klasse (z. B. int semester = 1;)
4. Rest des eigenen Konstruktor-Bodys (this.matrnr = matrnr;)

Merksatz: Oberklasse zuerst, dann Feld-Initializer, dann Body. Im super(...)-Aufruf darfst du noch nicht auf eigene, erst später gesetzte Felder zugreifen.

Sichtbarkeits-Modifier

Java hat 4 Sichtbarkeitsstufen (Modifier), die regeln wer von außen drauf zugreifen darf.

Eselsbrücke "PpPP": Public (alle), protected (Paket + Subklassen), package-private (nur Paket), private (nur eigene Klasse).

Feinheit bei protected: Eine Subklasse in einem anderen Paket erreicht protected-Member über this/super oder über eine Referenz vom Typ der Subklasse, aber nicht über eine reine Oberklassen-Instanz. protected ist damit offener als package-private, aber kein freier Zugriff von überall.

Zugriff in Aktion

Klasse Konto im Paket bank mit protected double saldo und private String pin:

// 1) Selbe Klasse (bank.Konto): alles erlaubt
this.saldo = 100;     // OK
this.pin = "1234";    // OK

// 2) Andere Klasse im selben Paket (bank.Filiale)
k.saldo = 100;        // OK     (protected ist im Paket sichtbar)
k.pin = "1234";       // FEHLER (private)

// 3) Subklasse in anderem Paket (web.OnlineKonto extends Konto)
this.saldo = 100;     // OK     (geerbt, über this)
fremdesKonto.saldo;   // FEHLER (protected, aber fremde Instanz)

// 4) Fremde Klasse in anderem Paket (web.Report)
k.saldo;              // FEHLER (protected, außerhalb Paket + keine Subklasse)

Encapsulation, warum private?

Felder private + Getter/Setter public ist die Standard-Konvention. So kontrollierst du den Zugriff.

public class Student {
    private int matrnr;  // privat, kein direkter Zugriff von außen

    public int getMatrnr() {
        return matrnr;
    }

    public void setMatrnr(int neueNr) {
        if (neueNr <= 0) throw new IllegalArgumentException("MatrNr muss positiv sein");
        this.matrnr = neueNr;  // hier kannst du Validation einbauen
    }
}

Student s = new Student(...);
// s.matrnr = -1;  // FEHLER, privat
s.setMatrnr(-1);    // FEHLER zur Laufzeit (Exception)

Vorteile:

1. Validation beim Setzen
2. Read-only Felder möglich (nur Getter, kein Setter)
3. Interne Änderungen möglich ohne dass externer Code bricht
4. Debugging einfacher, Breakpoint im Setter sieht alle Änderungen

Visualisierung

So sieht der Ablauf von new Student(...) als Skizze aus:

new Student("Müller", 1001)
        |
        v
  [Heap reservieren]        name=null, matrnr=0, semester=0
        |
        v
  [super(): Person(...)]    name gesetzt
        |
        v
  [Feld-Initializer]        semester = 1
        |
        v
  [Konstruktor-Body]        this.matrnr = matrnr
        |
        v
  Referenz s zeigt aufs fertige Objekt

Schalte unten durch die Schritte und achte darauf, wann die Felder initialisiert werden und ab wann sie zugreifbar sind:

Klausur-Checkliste

1. Default-Konstruktor verschwindet, sobald du selbst einen schreibst. Wenn du parameterlos auch brauchst → selbst hinzufügen.
2. this(...) als erste Zeile für Konstruktor-Chaining.
3. this.feld = feld löst Parameter-Feld-Konflikt.
4. private + Getter/Setter für Encapsulation. Public Felder sind Klausur-Anti-Pattern.
5. Sichtbarkeits-Reihenfolge: public > protected > package > private (von offen zu eng). Merkhilfe; protected hat außerhalb des Pakets spezielle Subklassen-Regeln.

Typische Stolpersteine

1. Konstruktor mit Return-Typ. Falsch: public void Student(...). Das ist eine normale Methode mit demselben Namen wie die Klasse, aber wegen void kein Konstruktor. Konstruktor: kein Rückgabetyp, nicht mal void.

2. Default-Konstruktor erwartet. Student s = new Student(); schlägt fehl, sobald du einen anderen Konstruktor definiert hast. Java erstellt ihn nicht mehr automatisch.

3. private Felder über Vererbung. Subklassen können private Felder der Oberklasse NICHT direkt zugreifen, nur über protected/public Getter. Häufiger Klausur-Fehler.

4. this(...) an falscher Stelle. Muss erste Zeile im Konstruktor sein. Wenn du erst this.x = 1; schreibst und dann this(...), gibt's Compile-Error.

5. Package-private vergessen. Wenn du keinen Modifier schreibst (int x;), ist es package-private, nicht private. Klausur-Frage.

Klausur-Beispielaufgabe

Beispiel (typischer Klausur-Stil, zur Übung konstruiert).

Gegeben:

public class Konto {
    private double saldo;
    public Konto(double start) { this.saldo = start; }
}

(a) Warum schlägt new Konto() fehl? (b) Kann eine Subklasse Sparkonto im selben Paket direkt auf saldo zugreifen? (c) Wie macht man saldo für Subklassen lesbar, ohne ihn frei beschreibbar zu machen?

Lösung:

• (a) Sobald ein eigener Konstruktor (Konto(double)) existiert, erzeugt Java keinen Default-Konstruktor mehr. new Konto() findet keinen passenden Konstruktor (no suitable constructor found).
• (b) Nein, saldo ist private, also nur innerhalb von Konto sichtbar, für Subklassen nicht direkt. Der Paket-Aspekt ändert daran nichts.
• (c) Einen public double getSaldo()-Getter (read-only) anbieten, oder saldo auf protected setzen, falls geerbte Schreibrechte gewollt sind. Für reines Lesen ist der Getter die sauberere Lösung.

Code-Stepper: Schritt für Schritt

Drei Demos zum Durchklicken. Klick Step oder Auto und beobachte, wie sich Variablen und Ablauf pro Schritt ändern.

1. Konstruktor-Chaining mit this(...)

Der 2-Argument-Konstruktor delegiert an den 3-Argument-Konstruktor und setzt semester auf den Default 1.

2. super(): Initialisierungs-Reihenfolge

Bei Vererbung läuft super() zuerst, dann die Feld-Initializer, dann der Body. Der Body kann einen Initializer-Wert überschreiben.

3. Encapsulation: Validierung im Setter

private plus Setter macht ungültige Zustände unmöglich, der Setter prüft vor dem Schreiben.

Klausur-Tipp: Bei Fehler "no suitable constructor found", du hast einen Konstruktor mit Parametern definiert und versuchst, das Objekt parameterlos zu erzeugen. Lösung: parameterlosen Konstruktor zusätzlich anlegen oder beim Aufruf Argumente liefern.

Konstruktoren + Sichtbarkeit, Praxis-Übung

6 Aufgaben zu Default-Constructor, Overloading, Sichtbarkeitsmodifier.