Ex astris scientia

Wenn man eigentlich denkt, man hat alles verstanden, steht man doch da, wie der Ochs’ vorm Berg. Das eine private gekennzeichnete Methode oder ein Feld nur von innerhalb der Klasse verwendet werden darf, ist glaube ich jedem klar – der sich ein klein wenig in der Materie auskennt. Auch die Hirnleistung, die aufgewendet werden muss, um zu begreifen, dass jeder und alles auf public Methoden und Felder zugreifen darf, hält sich in grenzen.

Doch wie war das mit protected? Erschreckend aber wahr: Das vor der letzten Java-Klausur auswendig Gelernte – langweilige Definitionen … usw. – reicht nicht (mehr) aus. Egal woran es lag, der Sinn von protected musste – von so manch einem – schmerzlich erfahren werden.

Einfaches Beispiel, Vater- und Sohnklasse:

public class Test1 {
	public Test1() {
		System.out.println(this.s());
	}
	protected String s() {
		return "Test 1";
	}
}

public class Test2 extends Test1 {
	protected String s() {
		return "Test 2";
	}
}

Wäre jetzt die Methode s() als private gekennzeichnet, so würden beide Klassen bei der Erzeugung einer Instanz “Test 1″ ausgeben.

Hört sich trivial an, ist mir gerade bei der GUI-Programierung über den Weg gelaufen: Ich wusste, das in der Superklasse der Konstruktor die Methode iniEvents() aufrief, den Konstruktor an sich wollte ich behalten. Nur passierte nichts als ich diese Methode überlagern – nicht überladen – wollte. Beide private Methoden iniEvents() hatten die selbe Signatur – mir ist leider nicht aufgefallen, das Eclipse keine kleines grünes “Override”-Dreieck anzeigte. Hatte dann jedes mal den gesamten Konstruktor erneuert, da ich die iniEvents() ja nicht überschreiben konnte – argh!

Jetzt bin ich schlauer, nicht nur weil ich lesen kann…