Warum kann ich, auf private Variablen zugreifen, wenn ich ein Objekt in der Klasse, die private Variablen hat erstelle und dort drauf zugreifen will?

[uuqfowehui23]

Mir ist aufgefallen, dass wenn ich z. B. eine Klasse A habe, die Klasse A hat 3 private Variablen.

Dann kann ich, wenn ich in der Klasse B ein Objekt der Klasse A habe, nicht auf die 3 privaten Variablen zugreifen, in der Klasse A selber schon, wenn ich in der Klasse A ein Objekt von A erstelle warum?...

 

[httpdigest]

Ist korrekt.
Alle Methoden innerhalb der Klasse A können auf alle privaten Member (Konstruktoren, Methoden, Felder) derselben Klasse A zugreifen.
Wenn du außerhalb der Klasse A bist (in deinem Fall in einer Methode einer anderen Klasse B), dann kannst du dort _nicht_ auf private Member der Klasse A zugreifen.

Etwas anderes wäre es z.B., wenn du in Klasse A eine public Methode definierst, und diese von der Methode in Klasse B (auf einer Instanz von A) aufrufst und diese public Methode in A dann auf ein private Feld von A zugreift. Dann hast du dich ja _explizit_ dafür entschieden, den privaten Zustand (das Feld) von A nach außen zu veröffentlichen, durch eben die public Methode in A.

Die Sichtbarkeitsspezifizierer (wie "private", "protected" und "public") sind also ein Mechanismus zur Kapselung (engl.: Information Hiding).

Die Frage ist also nicht, _was_ du aufrufst (private Methode in Klasse A), sondern _wer_ diese Methode aufruft (also von wo der Aufruf stattfindet) - in deinem Fall in einer Methode in einer anderen Klasse B.

 

[uuqfowehui23]

Ist korrekt.
Alle Methoden innerhalb der Klasse A können auf alle privaten Member (Konstruktoren, Methoden, Felder) derselben Klasse A zugreifen.
Wenn du außerhalb der Klasse A bist (in deinem Fall in einer Methode einer anderen Klasse B), dann kannst du dort _nicht_ auf private Member der Klasse A zugreifen.

Etwas anderes wäre es z.B., wenn du in Klasse A eine public Methode definierst, und diese von der Methode in Klasse B (auf einer Instanz von A) aufrufst und diese public Methode in A dann auf ein private Feld von A zugreift. Dann hast du dich ja _explizit_ dafür entschieden, den privaten Zustand (das Feld) von A nach außen zu veröffentlichen, durch eben die public Methode in A.

Die Sichtbarkeitsspezifizierer (wie "private", "protected" und "public") sind also ein Mechanismus zur Kapselung (engl.: Information Hiding).

Die Frage ist also nicht, _was_ du aufrufst (private Methode in Klasse A), sondern _wer_ diese Methode aufruft (also von wo der Aufruf stattfindet) - in deinem Fall in einer Methode in einer anderen Klasse B.

Okay danke

 

[White_Fox]

warum?.

Der Gedanke hinter einer Klasse ist es, das Verhalten eines Objektes zu beschreiben. Nach außen hin definierst du, WAS ein Objekt tut. Innerhalb der Klasse beschreibst du, WIE das Objekt etwas macht.

Wenn du z.B. eine Pizza bestellst, dann gibt es für dich als Kunden ein ganz klares Prozedere: Du rufst an und sagst was du willst. Dann steht jemand vor deiner Tür und drückt dir gegen Geld die Pizza in die Hand. Was zwischen deinem Anruf und dem Öffnen der Tür passiert, interessiert dich nicht und hat dich nicht zu interessieren. Z.B. ob die in der Pizzabäckerei eine Wagner warm machen oder selber backen. Und ob die Pizza von einem Mitarbeiter auf einen Fahrrad, Roller oder Auto gebracht wird, ob mit berittenem Boten oder per Hubschrauber genausowenig.
Es wäre natürlich denkbar, daß du dich um all das auch noch kümmerst, aber das wäre unsinnig.

Die Vorteile in der Programmierei sind vielfältig: Zum einen kannst du große Riesenprobleme in viele kleine, leicht verständliche und schnell lösbare Probleme zerlegen – der Kern der Ingenieurskunst schlechthin.
Außerdem machen Änderungen nicht dein ganzes Programm zunichte. Nimm z.B. eine Klasse, das Daten für dein Programm zur Verarbeitung liefert. Wenn die Daten nun anderswo herkommen sollen, z.B. willst du auf eine andere Datenbank umsteigen, so mußt du zwar eine Klasse umschreiben, aber der Rest deines Programms bekommt von dieser Änderung nix mit. Die Methoden, die die Klasse nach außen hin zur Verfügung stellt, haben denselben Namen, nehmen dieselben Parameter entgegen und liefern dieselben Daten zurück wie vorher.
Außerdem bieten dir Getter/Setter nachträglich z.B. Möglichkeiten zur Fehlerbehandlung an. Nimm z.B. mal an, du hast eine Klasse die in deinem Programm an sehr vielen Stellen verwendet wird. Diese Klasse hat einen Integerwert, und dieser Wert wird in deinem Programm – welches aus 5Mio Codezeilen besteht – an unzählig vielen Stellen per Direktzugriff gelesen und beschrieben.
Und zwei Jahre später stellt sich heraus: Dieses Integer darf niemals kleiner als 0 sein. Viel Spaß beim Codeeditieren.
Deutlich weniger Ärger würde so eine Änderung machen, wenn der Zugriff steht über Getter/Setter-Methoden erfolgt. Dann würdest du lediglich die eine Settermethode ändern müssen und wärst fertig.

 

[fhoffmann]

Ich denke, dass es dem Fragesteller mehr darum geht, warum der Zugriff über die Klasse und nicht über das Objekt beschränkt ist.
Etwas eigenartig ist das ja schon:
Wenn ein Mensch (ein Objekt der Klasse Mensch) ein privates Geheimnis hat, kann jeder andere Mensch darauf zugreifen.

 

[uuqfowehui23]

Ich denke, dass es dem Fragesteller mehr darum geht, warum der Zugriff über die Klasse und nicht über das Objekt beschränkt ist.
Etwas eigenartig ist das ja schon:
Wenn ein Mensch (ein Objekt der Klasse Mensch) ein privates Geheimnis hat, kann jeder andere Mensch darauf zugreifen.

Genau das ist meine Frage, also warum Java sowas supportet.

 

[LimDul]

Eine interessante Frage, die ich nicht beantworten kann. Was als Grund aufgeführt wird - private soll wie oben beschrieben die interne Implementierung einer Klasse A vor anderen Klassen verstecken. So dass man sie frei anpassen kann. Damit ist es "ok" wenn ein Objekt a1 der Klasse A (was ja die interne Implementierung kennt) auf private Field des Objektes a2 der Klasse A zugreifen kann. Es ist ja die gleiche interne Implementierung.

Einen echten Vorteil bietet es bei der equals Methode - zwei Objekte sind oft equals, wenn ihr interner Zustand identisch ist. Diesen internen Zustand möchte man aber nicht von außen zugreifbar machen. Durch diese Regel kann man direkt auf den internen Zustand des anderen Objektes der gleichen Klasse zugreifen.

 

[httpdigest]

Ob nun zwei Ausdrücke jeweils zum selben Objekt oder einem anderen Objekt (gemäß Identität) auswerten, lässt sich nicht zur Compilezeit entscheiden. Man hat sich bei Java nun mal eben dafür entscheiden, Zugriffsregeln zur Compilezeit* auszuwerten und zu enforcen. Ja, nebenbei gibt es natürlich auch noch die Java Core Reflection API, bei der diese Zugriffsregeln auch zur Laufzeit ausgewertet werden. Aber, in keinem Fall wird die Identität eines "aufrufenden Objektes" hier verwendet, sondern immer nur die statische Codestelle, bei der der Aufruf passiert.

Man kann also keinen Zustand eines Objektes der Klasse A von einem anderen Objekt (gemäß Objekt-Identität) der Klasse A "verstecken", weil man nicht weiß, ob das eine Objekt nicht auch dasselbe Objekt ist wie das andere.

EDIT:
*Korrektur: Genauer gesagt, zur Compilezeit _und_ zur Linking-Zeit vor dem ersten Zugriff (also während der Laufzeit).