Vererbungsarten in Java

[mapexo]

Hi!
In C++ kann man ja so vererben:

class TestB : protected TestA{ . .

In Java ist die Vererbung doch Standardmäßig immer public oder? Kann man überhaupt private- oder protected - vererben?

Danke im Voraus!

Mapexo

[Stefan Gawlick]

C++ kann ich nicht. Aber in Java ist es folgendermaßen:<br>
Die Sichtbarkeit der Oberklasse ist relevant, ob die Unterklasse überhaupt Unterklasse von dieser Oberklasse sein kann (toll formuliert, oder?).<br>
Die Unterklasse kann selbstverständlich eine von der Oberklasse vollkommen unabhängige Sichtbarkeit haben. Du könntest also von einer Oberklasse erben und die Unterklasse als protected definieren.<br>
<br>
Gruß,<br>
Stefa

[Thomas Kaufmann]

Java und C++ sind zwei Paar Schuhe, obwohl beide Sprachen bekanntermaßen dem objektorientierten Programmierparadigma verpflichtet sind - und Java ist unter anderem (!) nach dem Vorbild von C/C++ modelliert worden (Syntax, einige Konzepte). Da enden aber die Gemeinsamkeiten schon fast.

Der erste wesentliche Unterschied ist der, dass der Code in Java ausschließlich in Klassen organisiert wird (es gibt keine globalen Variablen oder dergleichen Methoden - ok, mit <i>static</i> erreicht man einen ähnlichen Effekt).

Selbstredend kennen natürlich beide Sprachen das Konzept der Vererbung. Das kann auch gar nicht anders sein, denn die Vererbung ist eine klassische Forderung der OOP! Der Vollständigkeit halber müssen noch die beiden anderen essentiellen Forderungen der OOP genannt werden: Polymorphismus und die Kapselung der Daten. Sie sind genauso wichtig.

Doch zrück zum interessanten Thema Vererbung: Ein weiterer eklatanter Unterschied zwischen beiden Sprachen ist das Konzept der Mehrfachvererbung, wie es in C++ umgesetzt worden ist (welches aber nicht unumstritten ist; trotzdem kann Mehrfachvererbung durchaus sinnvoll sein, wenngleich der Code erheblich komplexer wird). In Java kann der Anwender aber immerhin durch die Verwendung von Interfaces diese "Beschränkung" halbwegs ausgleichen.

Jetzt wird es langsam konkret. Denn im Kontext der Vererbung tauchen automatisch die berühmten Modifier auf: <i>private</i>, <i>protected</i> und <i>public</i>. Sie haben Einfluß auf die Lebensdauer, Sichtbarkeit und die Veränderbarkeit von Programmelementen, weshalb sie hier genauer unter die Lupe genommen werden müssen.

-<i>private</i>

Elemente dieses Typs sind nur in der Klasse sichtbar, in der sie definiert worden sind. Unterklassen bzw. Aufrufer von Instanzen können diese Elemente nicht "sehen".

-<i>protected</i>

Elemente dieses Typs sind in der Klasse selbst und in den Methoden abgeleiteter Klassen sichtbar; Klassen desselben Pakets dürfen diese Elemente ebenfalls aufrufen.

-<i>public</i>

Elemente dieses Typs sind in der Klasse selbst, in abgeleiteten Klassen und für Aufrufer von Instanzen der Klasse sichtbar.

Und zum guten Schluß: Falls ein Programmelement ohne Modifier deklariert ist, wird es als "Element mit Standard-Sichtbarkeit" (package scoped) eingeordnet. Das bedeutet nichts weiter, als dass solche Konstrukte nur innerhalb des Pakets sichtbar sind, zu dem die Klasse gehört.
Nach soviel grauer Theorie zur Praxis. In Java wird jede Klasse generell mit dem Modifier <i>pulic</i> deklariert (es gibt Ausnahmen, doch die sind hier nicht relevant). Und das sieht dann so aus:
<PRE>
public class MyClass {
...
...
}
</PRE>
Nun kann, wie bereits erwähnt, eine Klasse von einer anderen Klasse abgeleitet werden.
<PRE>
public class MySubClass extends MyClass{
...
...
}
</PRE>

<i>MyClass</i> wird in diesem Fall als Oberklasse (oder Superclass) bezeichnet, <i>MySubClass</i> hingegen als Unterklasse (oder als subclass).

Das Schlüsselwort <i>extends</i> (extends=erweitern) weist auf den Umstand hin, das geerbt wird; d.h. die Unterklasse erhält damit Zugriff auf die Attribute (state) und die Methoden (behavior) der Superklasse. Tatsächlich auf alle Attribute und Methoden der Oberklasse? Das kommt darauf an!

Denn zum Glück sorgen die Modifier für einen angemessenen Schutz der Membervariablen der Superklasse (Kapselung der Daten der Superklasse).

Vielmehr sollte der Aufrufer (<i>MySubClass</i>) gezwungen werden, über sogenannte Getter/Setter-Methoden (sie sind auch als Accessor-Methoden bekannt) auf die Attribute zuzugreifen.

Insbesondere die Setter-Methoden können - bei Bedarf - einen Validierungsmechanismus einbauen, denn dadurch wird der Schutz der Daten der Superklasse garantiert.

Keine Angst, der Overhead für Getter/Setter-Methoden fällt kaum ins Gewicht und ist in jedem Fall besser, als die Daten dem Aufrufer direkt preiszugeben. Ein Beispiel für die Verwendung von Getter/Setter-Methoden (und somit für Vererbung in Java):
<PRE>
public class MyClass {

private int age;

public void setAge(int a) {
if (a <= 0) {
System.out.println("\nBitte Alter nochmal eingeben!");

} else if (a > 0) {
this.age = a;
System.out.println("\nEingabe war ok.");
}
}

public int getAge() { return age; }
}
</PRE>
<PRE>
public class MySubClass extends MyClass {

public MySubClass() {}

public static void main (String[] args) {

MySubClass mysub = new MySubClass();
//mysub.age = 40;

mysub.setAge(0);
mysub.setAge(40);
System.out.println("\nIhr Alter: " + mysub.getAge());
}
}
</PRE>
Achtung: Es handelt um zwei verschiedene Dateien! Also, die Klasse <i>MyClass</i> befindet sich in einer Datei namens <i>MyClass.java</i>, der Code für <i>MySubClass</i> in einer Datei namens <i>MySubClass.java</i>, ok?

Kompilieren Sie das Beispiel so:
<PRE>
javac MySubClass.java
</PRE>
Der Aufruf erfolgt so:
<PRE>
java MySubClass
</PRE>
Wenn Sie den Kommentar vor <i>mysub.age</i> in <i>MySubClass</i> entfernen, wird der Code nich kompiliert. Der Compiler weist vielmehr darauf hin, daß die Variable <i>age</i> als <i>private</i> deklariert wurde - damit entfällt der direkte Zugriff auf diese Variable. Sie müssen (!) also den "Umweg" über die Methode <i>setAge()</i> nehmen. Und das ist auch gut so;-).

Im Übrigen befolgt man mit der Verwendung von Getter/Setter-Methoden den vorgegebenen Standard von SUN (Stichwort: Namenskonventionen).

Viel Spaß.

Thomas Kaufman