Info

Autor: HM_JDSZielgruppe: Sek I

Gueltigkeit und Sichtbarkeit

Dieses Kapitel basiert auf dem Arbeitsblatt zu "Sichtbarkeit und Lebensdauer von Variablen". Es verbindet drei Felder, die in Java regelmaessig zu Fehlern fuehren:

  1. scope (Sichtbarkeit)
  2. extent (Lebensdauer)
  3. Namensueberschattung und Vererbungskontexte

Zwei Grundbegriffe

Das Arbeitsblatt trennt sehr klar:

  • Sichtbarkeit (scope): Wo im Quelltext darf auf eine Variable zugegriffen werden?
  • Lebensdauer (extent): Wann existiert die Variable im Speicher?

Eine Variable kann also sichtbar sein, aber schon nicht mehr existieren, oder existieren, aber ausserhalb des aktuellen Scopes liegen.

Lokale Variable, Parameter, Instanzvariable

In der Praxis kommen drei Typen staendig vor:

  1. lokale Variablen innerhalb einer Methode
  2. Parameter der Methode
  3. Instanzvariablen (Attribute der Klasse)

Wenn Namen mehrfach verwendet werden, entsteht Ueberschattung.

Namensueberschattung und this

Das Arbeitsblatt zeigt klassische Beispiele:

class X {
    private int a;

    public void setA(int a) {
        this.a = a;
    }
}

Ohne this wuerde der Parameter a sich selbst zugewiesen werden. Mit this.a greifst du explizit auf das Attribut zu.

Dasselbe gilt, wenn in einer Methode eine lokale Variable denselben Namen traegt wie ein Attribut.

Zugriffsmodifier und Sichtbarkeit

Abbildung 1

Das Arbeitsblatt knuepft an OOP-I an:

  • private: nur in der eigenen Klasse
  • protected: in Klasse und Subklassen (plus package-Regeln)
  • public: allgemein sichtbar

Die Wahl des Modifiers bestimmt, welche Stellen im Programm ueberhaupt auf welche Daten zugreifen duerfen.

Sichtbarkeit in Vererbungssituationen

Das Arbeitsblatt enthaelt Aufgaben mit Klassenhierarchien (KlasseA, KlasseB, KlasseC) und ueberschriebenen Methoden.

Typische Fragen dabei:

  1. Welche Variable ist in methode1 sichtbar?
  2. Welche in methode2?
  3. Welche Ausgabe entsteht in main und warum?

Die richtige Loesung erfordert immer die Kombination aus:

  • statischem Typ der Referenz
  • dynamischem Typ des Objekts
  • scope-Regeln innerhalb der Methode

Wertebelegungstabellen als Technik

Das Arbeitsblatt fordert explizit Tabellen, in denen pro Programmschritt der Variablenwert notiert wird. Diese Technik ist sehr wirksam bei verschachtelten Methodenaufrufen.

Empfehlung:

  1. Zeilennummer/Schritt notieren
  2. relevante Variablen als Spalten
  3. nach jedem Sprung in Methode Werte aktualisieren
  4. Rueckspruenge und Rueckgabewerte markieren

Gerade bei gleichnamigen Variablen auf verschiedenen Ebenen verhindert das viele Denkfehler.

Beispielmuster: statisch vs. nicht-statisch

Das Blatt enthaelt auch Aufgaben mit statischen Variablen in Methodenketten.

Wichtige Unterscheidung:

  • static gehoert zur Klasse
  • Instanzvariablen gehoeren zu konkreten Objekten

Das hat unmittelbare Folgen fuer Sichtbarkeit und Lebensdauer:

  • Klassenvariablen leben, solange die Klasse geladen ist.
  • lokale Variablen leben nur waehrend des Methodenaufrufs.

Haeufige Fehler in diesem Kapitel

  1. this bei Ueberschattung vergessen Attribut wird nicht wie erwartet geaendert.
  2. Lebensdauer lokaler Variablen unterschaetzt Nach Methodenende sind sie weg.
  3. Sichtbarkeit mit Erreichbarkeit verwechselt Eine Referenz kann sichtbar sein, aber null enthalten.
  4. Vererbte Member falsch eingeschaetztprivate der Oberklasse ist in Subklasse nicht direkt sichtbar.
  5. statische und instanzbezogene Daten gemischt Fuehrt zu schwer nachvollziehbarem Zustand.

Methodische Loesestrategie fuer Sichtbarkeitsaufgaben

  1. Marker fuer jede Variable setzen: lokal, Parameter, Instanz, statisch.
  2. Bei Namensgleichheit sofort notieren, welche Ebene gemeint ist.
  3. Vor jedem Methodenaufruf aktuellen Zustand protokollieren.
  4. Bei Rueckkehr aus Methode Rueckgabewert und Seiteneffekte trennen.
  5. Erst danach Ausgabezeilen auswerten.

Diese Reihenfolge ist deutlich robuster als "im Kopf improvisieren".

Beispiel zur Klarstellung

class Test {
    private int k;

    public void methode1(int i) {
        k = i;
    }

    public int methode3(int i) {
        int k = i;
        return i * k;
    }
}

Hier gibt es zwei k:

  • Attribut this.k
  • lokale Variable k in methode3

Diese sind verschieden. Die lokale Variable ueberschattet das Attribut nur innerhalb der Methode.

Uebungsaufgaben zur Vertiefung

  1. Analysiere ein kleines Programm mit drei gleichnamigen Variablen (a) auf unterschiedlichen Ebenen.
  2. Erstelle eine vollstaendige Wertebelegungstabelle fuer den Ablauf.
  3. Schreibe ein Beispiel, in dem this.a noetig ist.
  4. Schreibe ein Beispiel mit static int x, das Methodenaufrufe ueber mehrere Zweige beeinflusst.
  5. Formuliere fuer jede Variable explizit: scope, Lebensdauer, Speicherort.

Praxishinweise fuer sauberen Code

  1. Namen nicht unnoetig mehrfach verwenden.
  2. Kurze Methoden reduzieren Scope-Komplexitaet.
  3. Seiteneffekte deutlich benennen (set..., update...).
  4. Bei kompliziertem Ablauf mit Debugger oder Tabelle arbeiten.
  5. private als Standard, Sichtbarkeit nur bei Bedarf oeffnen.

Zusammenfassung

Das Arbeitsblatt liefert die Kernbotschaft sehr deutlich:

  • Viele "mystische" Java-Fehler sind in Wahrheit Scope- und Lebensdauerfragen.
  • Wer Sichtbarkeit und Wertebelegung systematisch analysiert, loest solche Aufgaben reproduzierbar.
  • Diese Kompetenz ist Voraussetzung fuer sichere Arbeit mit Vererbung, Polymorphie und groesseren Projekten.

Scope-Analyse als feste Methode

Das Arbeitsblatt zeigt, dass viele Aufgaben nur dann sicher loesbar sind, wenn Scope und Lebensdauer explizit verfolgt werden. Eine robuste Methode besteht aus vier Schritten:

  1. Alle Variablen deklarationsnah markieren (lokal, Parameter, Instanz, statisch).
  2. Fuer jede Methode den sichtbaren Bereich notieren.
  3. Bei jedem Aufruf einen neuen Kontext aufmachen.
  4. Bei Rueckkehr den Kontext sauber schliessen.

Das ist im Prinzip ein manuelles Stack-Modell.

Namensgleichheit gezielt vermeiden

Ueberschattung ist in Java erlaubt, aber oft unnoetig riskant. Besonders in Lerncode gilt:

  • Parameter und Attribute nicht gleich benennen, wenn this noch unsicher ist.
  • Lokale Variablen mit klarer Rolle benennen (summe, count, index).

Wenn Namensgleichheit doch gebraucht wird, muss this konsequent genutzt werden.

Lebensdauer konkret im Methodenaufruf

Beispielmuster:

public int methode3(int i) {
    int k = i;
    return i * k;
}
  • Parameter i lebt waehrend des Aufrufs.
  • Lokale Variable k lebt ebenfalls nur waehrend dieses Aufrufs.
  • Instanzvariablen leben so lange wie das Objekt.

Diese Unterscheidung ist entscheidend fuer das Verstaendnis von Nebeneffekten.

Statische Variablen im Ablauf verfolgen

Das Blatt nutzt Aufgaben mit static-Feldern und mehreren Methoden. Dabei helfen zwei Regeln:

  1. Eine statische Variable ist pro Klasse genau einmal vorhanden.
  2. Jeder Aufruf kann denselben globalen Wert veraendern.

Deshalb sind statische Felder in Aufgaben mit rekursionsartigen Aufrufketten besonders fehleranfaellig.

Beispiel fuer Ueberschattung in einer Klasse

class Demo {
    private int a = 10;

    public void setA(int a) {
        this.a = a;
    }

    public void test() {
        int a = 3;
        System.out.println(a);      // lokale Variable
        System.out.println(this.a); // Attribut
    }
}

Dieses minimale Beispiel deckt den Kern vieler Blattfragen ab.

Wertebelegungstabellen richtig fuehren

Damit Tabellen wirklich helfen, sollten sie standardisiert sein:

Spalten:

  1. Programmschritt oder Zeilennummer
  2. aktive Methode
  3. lokale Variablen
  4. Instanzvariablen
  5. statische Variablen

Bei jedem Methodenwechsel wird eine neue Zeile geschrieben. So bleiben Spruenge und Rueckkehrpunkte nachvollziehbar.

Typische Fehlmuster bei Sichtbarkeitsaufgaben

  1. Attributwert mit lokalem Wert verwechselt.
  2. Annahme, dass private in Subklasse direkt sichtbar ist.
  3. Vergessen, dass static klassenweit geteilt ist.
  4. Rueckgabewert mit Seiteneffekt gleichgesetzt.
  5. Variablenzustand nur am Ende statt schrittweise betrachtet.

Uebungspaket fuer Vertiefung

  1. Schreibe eine Klasse mit Attribut x, Methode setX(int x) und lokaler x in zweiter Methode.
  2. Erstelle Tabelle fuer einen Ablauf mit drei Methodenaufrufen.
  3. Ergaenze eine statische Variable und wiederhole die Analyse.
  4. Fuehre Vererbung ein und pruefe Sichtbarkeit von private vs protected.
  5. Begruende jede Ausgabezeile schriftlich.

Diese Reihe entspricht dem Aufgabencharakter des Arbeitsblatts.

Debugging-Hinweise fuer Praxiscode

Wenn unerwartete Werte auftauchen:

  1. Suche nach Namensgleichheit zwischen Parametern und Attributen.
  2. Pruefe, ob this fehlt.
  3. Pruefe, ob statische Felder unerwartet mitveraendert werden.
  4. Pruefe, ob eine Methode Werte nur lokal aendert statt am Objekt.
  5. Setze gezielte Log-Ausgaben an Methodenanfang und -ende.

Bewertungsraster fuer Lernkontrollen

  1. Scope korrekt erkannt.
  2. Lebensdauer korrekt beschrieben.
  3. Ueberschattung korrekt aufgeloest.
  4. Statische und instanzbezogene Werte getrennt analysiert.
  5. Ausgaben schrittweise und nachvollziehbar begruendet.

Warum dieses Kapitel so wichtig ist

Viele spaetere Probleme in OOP-II wirken auf den ersten Blick "kompliziert", sind aber in Wahrheit Scope-/Sichtbarkeitsfehler. Wer dieses Kapitel sicher beherrscht, kann Polymorphie- und Vererbungsaufgaben deutlich stabiler loesen.

Abschluss

Das Arbeitsblatt liefert mit Sichtbarkeit und Lebensdauer ein Analysewerkzeug, das weit ueber Einsteigeraufgaben hinausgeht. Die konsequente Tabellenmethode macht komplexe Programmablaeufe transparent und reduziert Fehlinterpretationen drastisch.

Abschlussaufgabe zu Scope und Lebensdauer

Erstelle ein kleines Programm mit drei Klassen, in dem absichtlich gleichnamige Variablen auf verschiedenen Ebenen vorkommen.

Aufgabe:

  1. Fuehre das Programm aus und notiere alle Ausgaben.
  2. Erstelle eine Wertebelegungstabelle ueber den gesamten Ablauf.
  3. Markiere fuer jede Variable Scope und Lebensdauer.
  4. Ersetze anschliessend alle kritischen Namensgleichheiten durch bessere Namen und vergleiche die Lesbarkeit.

Diese Aufgabe macht den Kern des Arbeitsblatts praxisnah sichtbar.

Pruefungsnahe Kurzfragen

  1. Definiere Scope und Lebensdauer in je einem Satz.
  2. Wann verdeckt eine lokale Variable ein Attribut?
  3. Welche Rolle spielt this bei Namensgleichheit?
  4. Warum sind Wertebelegungstabellen bei komplexen Aufrufen hilfreich?

Diese Fragen pruefen direkt die Analysefaehigkeit aus dem Arbeitsblatt.

Weiterfuehrende Praxisaufgabe

Analysiere ein kleines Programm mit drei Methoden, einer Klassenvariable und zwei Instanzvariablen.

Arbeitsauftrag:

  1. Zeichne den Aufrufverlauf als Sequenz.
  2. Erstelle eine Wertebelegungstabelle fuer jeden Methodeneintritt und -austritt.
  3. Markiere in jeder Zeile, welche Variablen sichtbar sind.
  4. Notiere, wann lokale Variablen den Scope verlassen.

Abschlussfrage:

  • Welche konkrete Codeaenderung reduziert Verwechslungsgefahr am staerksten (Umbenennen, Aufteilen, Kapseln)?

Diese Praxisaufgabe verbindet Scope-Theorie mit konkreter Debug-Arbeit.

Mini-Reflexion

Wenn in einer Aufgabe ein Wert "unerwartet" ist, sollte zuerst nicht der Algorithmus verdaechtigt werden, sondern die Sichtbarkeitslage: Welche Variable mit gleichem Namen ist gerade aktiv, und welche wurde tatsaechlich geaendert? Diese Denkweise spart in Scope-Aufgaben sehr viel Zeit.

Zusatzaufgabe

Schreibe eine Methode, in der ein Parameter denselben Namen wie ein Attribut hat, und dokumentiere den Unterschied zwischen Zugriff mit und ohne this. Fuehre danach dieselbe Methode mit umbenannten Parametern aus und vergleiche Lesbarkeit und Fehlerrisiko.

Schlussgedanke

Scope-Probleme wirken oft unsichtbar, bis ein Wert "unerwartet" kippt. Wer systematisch in Kontexten denkt (Klasse, Objekt, Methode, Block), loest solche Fehler deutlich schneller und mit weniger Trial-and-Error.

Als Faustregel gilt: Je mehr Namensgleichheiten und statische Nebenwirkungen in einem Codeabschnitt auftreten, desto konsequenter sollte mit Tabellen, klaren Variablennamen und kurzen Methoden gearbeitet werden.