Übergeordnete Objekte abrufen

[Galliad]

In meinem Programm gibt es die Klasse A.
Objekte der Klasse A, wie zum Beispiel a, haben eine Arrayliste.
Diese Arrayliste ist mit Objekten der Klasse B gefüllt.
Manche Objekte der Klasse wie, wie zum Beispiel b, haben nun eine Methode, mit der sie auf eine Variable von a zugreifen müssen.
wie kann ich von der Methode, die von b ausgeführt wird, oder auch einer Methode, die von B als static Methode ausgeführt wird, auf diese Variablen von a zugreifen?

die Kleinbuchstaben sind hier immer Objekte, die Großbuchstaben Klassen.

 

[kneitzel]

Damit dieser Zugriff möglich ist, sind zwei Dinge notwendig:
- b benötigt eine Referenz auf a. Dies kann z.B. in Form einer Referenz, die b gegeben wurde statt finden.
- B benötigt zugriff auf das Attribut in A, z.B. über einen Getter.

 

[Galliad]

würde es nicht genügen, wenn die Variable public ist?
ich verzichte eigentlich meistens auf Getter und Setter, und halte die Variablen public. Das macht das Autocomplete schneller.
Wie sähe so eine Referenz denn aus?

 

[Neumi5694]

würde es nicht genügen, wenn die Variable public ist?
ich verzichte eigentlich meistens auf Getter und Setter, und halte die Variablen public. Das macht das Autocomplete schneller.
Wie sähe so eine Referenz denn aus?

Genügen ... ja
Aber: TU ES NICHT!
Keine public Variablen, niemals nie nicht, auf keinen Fall!
Public Variablen sind ein großes Nono.
Es gibt nur äußerst wenige Fälle, in denen sie sinnvoll sind (und seeeeehr alten Java-Code wie die awt Point Klassen und ähnliches).

Und wenn niemand außer der abgeleiteten Klasse darauf zugreifen können soll, dann verwende "protected", genau dafür ist es da.

Schreib brav Getter und Setter. Einige moderne Sprachen wie C# scheinen direkten Zugriff zu erlauben, aber dabei handelt es sich nur um vereinfachten Code. Der Compiler wandelt diesen um in die benötigten Getter und Setter.

 

[kneitzel]

Ein wichtiges Konzept bei der objektorientierten Entwicklung ist die Kapselung.

Das lässt sich etwas vereinfacht darstellen als: Was wie im inneren einer Klasse ist, geht niemanden außerhalb an. Das ist wichtig, damit eine Klasse möglichst unabhängig ist. Dies ist z.B. wichtig, wenn die Klasse irgend wann mal geändert werden soll.

Natürlich sollte eine Klasse auch von außen benutzbar sein. Dazu dient aber dann ein Interface (allgemein gesprochen - mein noch nicht das Interface bei Java), über das diese Interaktion erfolgt. Beispiel Auto: Man hat gelernt, mit einem bestimmten Interface klar zu kommen: Lenkrad, Schalthebel, Pedale, ... Das konkrete Auto spielt da dann keine Rolle und man kann jedes Auto fahren, dass diesem Interface folgt.

Das findet sich dann zwar auch ähnlich in der Programmierung wieder und man arbeitet viel gegen Interfaces. Aber es geht nicht darum, immer wirkliche Interfaces zu haben. Es geht um eine konkrete Außenschnittstelle. Und die hat man mit Methoden. Was da dann genau in der Methode passiert, ist egal.

Du hast eine Klasse DatumUhrzeit. Wie Du Datum und Uhrzeit speicherst, ist da erst einmal egal. Eine Methode "getSecondsSince1970()" wäre denkbar. Ebenso setSecondsSince1970. Das bedeutet aber nicht, dass es auch genau so gespeichert wird. Das kann auch umgerechnet werden. Als Entwickler ist man also frei, die Implementierung jederzeit anzupassen. Esmüssen dann ggf. nur die Methoden auch angepasst werden, damit das Interface immer noch erfüllt ist.

Das ist somit einfach nur sowas wie ein Best Practice und gehört mit zu dem Bereich, den ich immer als Clean Code umzeichne.

 

[Galliad]

Genügen ... ja
Aber: TU ES NICHT!
Keine public Variablen, niemals nie nicht, auf keinen Fall!
Public Variablen sind ein großes Nono.
Es gibt nur äußerst wenige Fälle, in denen sie sinnvoll sind (und seeeeehr alten Java-Code wie die awt Point Klassen und ähnliches).

Und wenn niemand außer der abgeleiteten Klasse darauf zugreifen können soll, dann verwende "protected", genau dafür ist es da.

Schreib brav Getter und Setter. Einige moderne Sprachen wie C# scheinen direkten Zugriff zu erlauben, aber dabei handelt es sich nur um vereinfachten Code. Der Compiler wandelt diesen um in die benötigten Getter und Setter.

die Klassen SIND aber in Abhängigkeit designt.

Ein wichtiges Konzept bei der objektorientierten Entwicklung ist die Kapselung.

Das lässt sich etwas vereinfacht darstellen als: Was wie im inneren einer Klasse ist, geht niemanden außerhalb an. Das ist wichtig, damit eine Klasse möglichst unabhängig ist. Dies ist z.B. wichtig, wenn die Klasse irgend wann mal geändert werden soll.

Natürlich sollte eine Klasse auch von außen benutzbar sein. Dazu dient aber dann ein Interface (allgemein gesprochen - mein noch nicht das Interface bei Java), über das diese Interaktion erfolgt. Beispiel Auto: Man hat gelernt, mit einem bestimmten Interface klar zu kommen: Lenkrad, Schalthebel, Pedale, ... Das konkrete Auto spielt da dann keine Rolle und man kann jedes Auto fahren, dass diesem Interface folgt.

Das findet sich dann zwar auch ähnlich in der Programmierung wieder und man arbeitet viel gegen Interfaces. Aber es geht nicht darum, immer wirkliche Interfaces zu haben. Es geht um eine konkrete Außenschnittstelle. Und die hat man mit Methoden. Was da dann genau in der Methode passiert, ist egal.

Du hast eine Klasse DatumUhrzeit. Wie Du Datum und Uhrzeit speicherst, ist da erst einmal egal. Eine Methode "getSecondsSince1970()" wäre denkbar. Ebenso setSecondsSince1970. Das bedeutet aber nicht, dass es auch genau so gespeichert wird. Das kann auch umgerechnet werden. Als Entwickler ist man also frei, die Implementierung jederzeit anzupassen. Esmüssen dann ggf. nur die Methoden auch angepasst werden, damit das Interface immer noch erfüllt ist.

Das ist somit einfach nur sowas wie ein Best Practice und gehört mit zu dem Bereich, den ich immer als Clean Code umzeichne.

ja okay. Aber damit weiß ich immer noch nicht wie ich das spezielle Objekt a finde, welches diesem speziellen b übergeordnet ist.

 

[kneitzel]

ja okay. Aber damit weiß ich immer noch nicht wie ich das spezielle Objekt a finde, welches diesem speziellen b übergeordnet ist.

@Neumi5694 hat sich auf das public bezogen. Wie in #2 gesagt: Du brauchst eine Referenz in b auf a. Und diese musst Du setzen. Wenn b eine Referenz auf ein A hat (z.B. "parent" genannt, so dies die Beziehung der Objekte ist), dann kannst Du in b auf dies zugreifen.

 

[Galliad]

@Neumi5694 hat sich auf das public bezogen. Wie in #2 gesagt: Du brauchst eine Referenz in b auf a. Und diese musst Du setzen. Wenn b eine Referenz auf ein A hat (z.B. "parent" genannt, so dies die Beziehung der Objekte ist), dann kannst Du in b auf dies zugreifen.

es besteht keine Child-Parent Beziehung zwischen A und B und kann es auch nicht geben. Wie würde ich sonst eine Referenz machen?

 

[Neumi5694]

Ein Objekt kennt seinen "Besitzer" nicht, es können ja mehrere Felder auf das selbe Objekt verweisen.
So was wie übergeordnete Objekte oder Besitzer gibt's im Grunde gar nicht, es gibt nur Referenzen auf Objekte und den Ort, wo die Referenz gespeichert ist, z.B. kann st du im Konstruktor mit übergeben, wer der Parent ist.
B b = new B(A.this);

 

[Galliad]

Ein Objekt kennt seinen "Besitzer" nicht, es können ja mehrere Felder auf das selbe Objekt verweisen.
So was wie übergeordnete Objekte oder Besitzer gibt's im Grunde gar nicht, es gibt nur Referenzen auf Objekte und den Ort, wo die Referenz gespeichert ist, z.B. kann st du im Konstruktor mit übergeben, wer der Parent ist.
B b = new B(A.this);

okay, damit kann ich was anfangen