Wenn eine Unterklasse private Mitglieder von einer Oberklasse nicht erben kann, aber sie erbt öffentliche Methoden von der Oberklasse, die Zugriff auf die privaten Mitglieder haben, die nicht vererbt werden, wie hier erwähnt
Wo sind die privaten Mitglieder der Super-Klasse, die von vererbten Mitgliedern der Unterklasse verändert wurden? Wo existieren sie?
Stellen Sie sich die privaten Mitgliedsvariablen so vor, als würden sie in der Klasse leben, in der sie deklariert sind. Wenn eine Unterklasse eine Methode in ihrer übergeordneten Klasse aufruft, die die Elementvariable ändert, denken Sie, dass diese Änderung in der übergeordneten Klasse geschieht. Dies ist eine nützliche Methode, um es in Ihrem Kopf zu modellieren, da nur diese Elternklasse über Code verfügen kann, der den Wert dieser Variablen liest oder schreibt.
Die Unterklasse muss eine Anfrage an die Elternklasse stellen und dann etwas mit der dort deklarierten Mitgliedervariablen machen.
Wenn Sie eine Methode in einer übergeordneten Klasse mit Code in der Unterklasse überschreiben, kann diese überschreibende Methode nicht auf die private Membervariable zugreifen, obwohl die überschriebene Methode im übergeordneten Element dies tut. Die überschreibende Methode in der Unterklasse kann die überschriebene Methode jedoch im übergeordneten Element aufrufen.
Zum Beispiel:
%Vor%Low Level Info:
Auf einer niedrigen Ebene kann ich jedoch eine Instanz von SubClass erstellen, die einen Speicherblock mit Platz für alle Instanzvariablen für SubClass und alle übergeordneten Klassen bis einschließlich Object reserviert.
Der Code für die Methoden selbst liegt in etwas Speicher, der von irgendeinem ClassLoader für die Klasse zugewiesen wird, die jede Methode enthält. Das wird auf einer Klasse-für-Klasse-Basis zugewiesen. Der Code der verschiedenen Sub- und Elternklassen wird also nicht zusammen gespeichert, obwohl die Daten in den Instanzen zusammen gespeichert sind.
Die Zugriffsregeln lassen den Code in SubClass nicht auf den Speicher zugreifen, der für die Instanzvariablen reserviert ist, die für eine Parent oder eine Vorgängerklasse privat sind.
In diesem Fall lohnt es sich jedoch selten, so detailliert darüber nachzudenken. Das ist meine Erfahrung damit. Andere sehen es vielleicht anders.
Hinweis: Es gibt Möglichkeiten, auf private Variablen durch Reflektion zuzugreifen.
Sichtbarkeit
Ich brauche hier vielleicht Hilfe, wenn ich aus dem Gedächtnis arbeite.
Den Member-Variablen sind vier Ebenen der Sichtbarkeit zugeordnet. Dies sind die gleichen vier Klassenvariablen und Methoden.
privat - auf diese Variablen kann nur durch Code innerhalb derselben Klasse zugegriffen werden, in der sie deklariert sind. (Nun ... sie können auch durch innere Klassen innerhalb dieser Klasse erreicht werden.)
Paket - auf diese kann durch Code innerhalb derselben Klasse UND Code in jeder Klasse im selben Paket wie diese Klasse zugegriffen werden. Die Klasse mit diesem Code könnte in Ihren Quelldateien oder in einer JAR-Datei oder wirklich irgendwo im Klassenpfad enthalten sein. (Hinweis: Es gibt kein Schlüsselwort "package". Eine Variable hat Sichtbarkeit auf Paketebene, wenn kein anderes Schlüsselwort die Sichtbarkeit angibt. Ich lege gerne das Wort "package" in einen Kommentar von / * * /.)
protected - auf diese kann durch Code innerhalb derselben UND-Code-Klasse in jeder Unterklasse dieser Klasse zugegriffen werden UND-Code in jeder Klasse in demselben Paket wie diese Klasse.
public - auf diese kann durch Code innerhalb jeder anderen Klasse zugegriffen werden.
Warnung: Es gibt auch Möglichkeiten, dass Code, den Sie sonst erwarten würden, nicht sichtbar ist. Dies liegt an der Arbeitsweise der ClassLoader. Java EE verfügt über eine Schachtelung von Klassenladeprogrammen, und Sie können am Ende Code anzeigen, der von einem Klassenladeprogramm geladen wurde, das für Code, der von einem anderen geladen wird, nicht sichtbar ist. Sie können zwei Klassen mit demselben vollständigen Namen (einschließlich Paket) erhalten. Ich halte das alles für ein "fortgeschrittenes" Thema, und ich müsste darüber nachdenken, um es zu erklären. Ich wollte bemerken, dass es passiert und Sie dazu bringen können, sich über Sichtbarkeit Gedanken zu machen.
%Vor%Ein letzter, praktischer Hinweis: Ich finde es auf lange Sicht extrem nützlich, fast alle Mitgliedsvariablen privat zu machen. Wenn Sie sie ändern müssen, um etwas sichtbar zu machen, tun Sie dies ODER vielleicht nur Getter und Setter-Methoden mit der gewünschten Sichtbarkeit. Ein Vorteil ist, dass ich nur Lesezugriff gewähren kann, wenn ich einen Getter und keinen Setter bereitstelle oder wenn der Getter öffentlich ist und der Setter geschützt ist. Ich kann auch eine writeonly-Variable erstellen, die gesetzt, aber niemals gelesen werden kann. Dies funktioniert mit der Abhängigkeitsinjektion, aber Sie sollten einen Kommentar dazu schreiben. Vielleicht können Sie die Vorteile sehen. Der Nachteil ist, dass Sie mehr Codezeilen schreiben, aber Eclipse unter anderen IDEs generiert diese Methoden für Sie, wenn Sie möchten.
Eine Instanz der Unterklasse enthält alle Mitglieder ihrer Oberklassen, jedoch kann nicht auf private Mitglieder innerhalb der Unterklasse zugegriffen werden.
Tags und Links java