Getter und Setter auch intern benutzen - guter Stil?

[Java.xzy]

Hallo!

Die Frage ist schnell erläutet: Datan kann man ja durch private und den Einsatz von gettern und settern schön nach außen kapseln.
Wie sieht die Verwendung allerdings intern in der Klasse aus? Hier kann ich ja problemlos auf die privaten Attribute zugreifen, ich könnte aber genau so gut deren getter und setter verwenden, wie es alle externen Aufrufer auch machen.

Was ist besser?

Als ich mir diese Frage gestellt habe, bin ich außerdem auf etwas gestoßen, was ich nicht verstehe.
Normalerweise werden als private deklarierte Attribute ja nicht an Subklassen vererbt. Der dazugehörige public-Setter allerdings schon. Warum kann ich jetzt eine Instanz der Subklasse erzeugen, auf dieser über den Setter ein bestimmtes Attribut setzen, welches eigentlich in der superklasse als private deklariert ist und in der Subklasse unbekannt sein müsste?

Danke

 

[Joew0815]

Hallo

Datan kann man ja durch private und den Einsatz von gettern und settern schön nach außen kapseln.

Das ist schonmal Quatsch, wird aber gerne in Foren etc. weiterezählt, ohne vorher darüber nachzudenken.

Normalerweise werden als private deklarierte Attribute ja nicht an Subklassen vererbt.

Natürlich werden sie das, jede Unterklasse hat alle Attribute ihrer Oberklassen, würde ja auch anders gar keinen Sinn machen.

 

[DarkLegend]

IMMER die getter und setter nutzen!
Auch wenns es bei reinen gettern und settern erstmal sinnlos erscheint...
du kannst so jederzeit z.B. in den Settern eine Validierung der Werte einbauen, ohne dass du dann das ganze bestehende Coding anfassen musst.

Also ich kann dir nur empfehlen, es immer zu nutzen!

 

[Sonecc]

Das ist schonmal Quatsch, wird aber gerne in Foren etc. weiterezählt, ohne vorher darüber nachzudenken.

Wie manche leute doch ihr pseudo wissen grunds. als Fakt hinstellen :lol:

 

[Java.xzy]

Natürlich werden sie das, jede Unterklasse hat alle Attribute ihrer Oberklassen, würde ja auch anders gar keinen Sinn machen.

Achja? Galileo Openbook meint:

Durch den Vererbungsmechanismus werden alle sichtbaren Eigenschaften der Oberklasse auf die Unterklasse übertragen. [...]
Die Vererbung kann durch private eingeschränkt werden. Eine Subklasse erbt dann alles von einer Superklasse, was nicht private ist.



Ansonsten danke mal. Also verwende ich auch intern Getter und Setter.
Nur beim Problem mit der Sichtbarkeit stehe ich gerade auf dem Schlauch.

 

[Tobse]

Ich denke das meint public

 

[Sonecc]

Private Mitglieder einer Klasse sind und bleiben Privat.
Unterklassen können sie definitiv nicht nutzen!!!

Wäre auch aus OOP Sicht völliger Schwachsinn, wenn es nicht so wäre

Einzig innere Klassen können das. Sonst NICHTS und NIEMAND!

Sry, aber was Joew0815 da sagt ist vom ersten Buchstaben an unsinn

 

[Noctarius]

Sry, aber was Joew0815 da sagt ist vom ersten Buchstaben an unsinn

ACK

 

[Joew0815]

Wie manche leute doch ihr pseudo wissen grunds. als Fakt hinstellen :lol:

Meine Rede...

IMMER die getter und setter nutzen!

q.e.d.

Achja? Galileo Openbook meint:
Durch den Vererbungsmechanismus werden alle sichtbaren Eigenschaften der Oberklasse auf die Unterklasse übertragen. [...]
Die Vererbung kann durch private eingeschränkt werden. Eine Subklasse erbt dann alles von einer Superklasse, was nicht private ist.

Dann ist das Buch offensichtlich falsch, dass alle Attribute vererbt werden kannst du doch an jedem OOP Beispiel nachvollziehen.

Private Mitglieder einer Klasse sind und bleiben Privat.
Unterklassen können sie definitiv nicht nutzen!!!

Anscheinend verwechselst du Sichtbarkeit mit Existenz, hättest du den ersten Post gelesen, wüsstest du, dass es darum hier überhaupt nicht geht.

Sry, aber was Joew0815 da sagt ist vom ersten Buchstaben an unsinn

Unglaublich, wie man hier (neuerdings??) von manchen runtergemacht wird, weil sich einige beleidigt oder bedroht fühlen. War früher anders hier...

 

[0x7F800000]

IMMER die getter und setter nutzen!
Auch wenns es bei reinen gettern und settern erstmal sinnlos erscheint...
du kannst so jederzeit z.B. in den Settern eine Validierung der Werte einbauen, ohne dass du dann das ganze bestehende Coding anfassen musst.

Also ich kann dir nur empfehlen, es immer zu nutzen!

Und ich bin kategorisch gegen jegliche Pauschalisierungen^^

Ich finde es eigentlich sinnvoller, die zur Verfügung stehenden Sprachmittel sinnvoll einzusetzen, statt alles grundsätzlich mit Tonnen von Boilerplate-Code zu überfüllen. Habe gestern eine wunderschöne Klasse für Immutable AVL-Bäume geschrieben: ohne jegliche veränderliche Member-Variablen, ohne jegliche Getter oder Setter. Wozu brauche ich denn auch Setter, wenn eh alles final ist? Und wozu brauche ich dann getter, wenn ich eh alles gefahrlos protected statt private deklarieren kann?

Ich will mir jedenfalls nicht ausmalen, wie es aussehen würde, wenn ich so eine Doppelrotation intern mit Gettern und Standard-Konstruktoren ausformulieren müsste:

return tree(
		tree(this.left,this.entry,newRight.left.left),
		newRight.left.entry,
		tree(newRight.left.right,newRight.entry,newRight.right)
);

würde dann zu sowas wie

return new PersistentAVLTreeMap<K,V>(
		new PersistentAVLTreeMap<K,V>(this.getLeft(),this.getEntry(),newRight.getLeft().getLeft()),
		newRight.getLeft().getEntry(),
		new PersistentAVLTreeMap<K,V>(newRight.getLeft().getRight(),newRight.getEntry(),newRight.getRight())
);

werden. Und wem nützt dieser Salat jetzt? Trägt es zur Übersicht bei? Oder zur Wartbarkeit? Oder macht es den Code weniger fehleranfällig? Ich würde sagen: drei Mal "Nein". Es ist lediglich schwerer zu tippen und zu lesen.

PS: selbstverständlich, wenn man mit code zu tun hat, der erweiterbar sein soll, und dessen Aufgaben nicht von Anfang an messerscharf eingegrenzt sind, ist man mit settern & gettern auf der sicheren Seite. Das betrifft imho aber nur Variablen, die irgendwas mit dem Interface zu tun haben. Für private, ausschließlich intern verwendete variablen machen getter/setter imho wenig sinn, solange man sich sicher ist, dass man selbst niemals ihre veränderungen kontrollieren/überwachen will.

 

[faetzminator]

Ich glaube, da werden einfach ein paar Ausdrücke falsch eingesetzt und verstanden. Je nach Interpretation des Lesers haben beide Recht: Das Feld steht natürlich auch zur Verfügung, aber dank der Sichtbarkeit nur der jeweiligen Oberklasse.

 

[Java.xzy]

Ich dachte ich hätte es damals kapiert, aber wohl doch nicht. Also folgendes kompiliert schon garnicht, also werden private Attribute wohl doch nicht vererbt und das Buch hat recht ?!? Mit protected gehts übrigens.

public class A {

	private String vorname;
}

public class B extends A {
	
	public void get() {
		System.out.println(vorname);
	}
}

 

[eRaaaa]

Dann ist das Buch offensichtlich falsch, dass alle Attribute vererbt werden kannst du doch an jedem OOP Beispiel nachvollziehen.

Anscheinend verwechselst du Sichtbarkeit mit Existenz, hättest du den ersten Post gelesen, wüsstest du, dass es darum hier überhaupt nicht geht.

Mhm..dann scheinst du wohl auch mehr zu wissen als sun/oracle

Private Members in a Superclass
A subclass does not inherit the private members of its parent class. However, if the superclass has public or protected methods for accessing its private fields, these can also be used by the subclass.

 

[faetzminator]

@TO:
Doch, weil wenn es nicht vererbt werden würde, würde folgendes nicht gehen:

public class A {
 
    private String vorname;

    public String getVorname() {
        return vorname;
    }
}
 
public class B extends A {
    
    public void get() {
        System.out.println(getVorname());
    }
}

Edit: @eRaaaa: da hast du natürlich Recht, aber wie bereits gesagt, die meisten wissen wie es gemeint ist und verstehen unter den Begriffen etwas anderes.

 

[Joew0815]

Liest in diesem Forum eigentlich auch irgendeiner mal die tatsächliche Frage, oder ist das inzwischen aus der Mode? Hier nochmal für Scrollfaule:

Als ich mir diese Frage gestellt habe, bin ich außerdem auf etwas gestoßen, was ich nicht verstehe.
Normalerweise werden als private deklarierte Attribute ja nicht an Subklassen vererbt. Der dazugehörige public-Setter allerdings schon. Warum kann ich jetzt eine Instanz der Subklasse erzeugen, auf dieser über den Setter ein bestimmtes Attribut setzen, welches eigentlich in der superklasse als private deklariert ist und in der Subklasse unbekannt sein müsste?

 

[Java.xzy]

Hm, also jetzt würde ich es nochmal gerne genau wissen.

Fakt scheint ja zu sein, dass private Attribute nicht vererbt werden. Fakt ist allerdings auch, dass man trotzdem draufzugreifen kann, wenn die Superklasse einen Getter bereitstellt.

Warum sucht der Getter das Attribut aber nicht in der abgeleiteten Klasse (wo er sich selbst auf befinden müsste, denn er ist ja public und somit an B vererbt worden), sondern in der Superklasse?

 

[Noctarius]

Also das Field wird rein faktisch schon vererbt ist aber aus der Subclass nicht sichtbar, da die Sichtbarkeit auf der Superclass liegt, da private.

Der Getter / Setter aus der Superclass mit Sichtbarkeit kann aber auf dieses Feld zugreifen. Überschreibst du in der Subclass den Getter / Setter geht dies aber nicht mehr, da hier wieder die Sichtbarkeit fehlt.

 

[Java.xzy]

Danke erstmal. Oh mann, ich geh kaputt. Ich dachte bisher immer, es wird das vererbt, was man von der Kindposition aus auch sehen kann. Und das war nicht mal dumm, denn das funktioniert in der Anwendung dann, als wäre das tatsächlich so.

Das hier ist der allererste Fall, bei dem es doch Probleme gibt und ich hab das immernoch nicht verstanden. also doch, ich habe schon verstanden was du geschrieben hast und kann es auch nachvollziehen, aber begreifen will ich es nicht. Praktisch jedes Javabuch, inklusive des hochgelobten Openbook von Galileo beschreibt es doch so. Selbst Sun, wenn man das Zitat von Era liest.
Kann doch nicht sein...

 

[Noctarius]

Wieso nicht, Vererbung hat ja nicht direkt mit der Sichtbarkeit zu tun.

Es gibt Public, Protected, Private und die Sichtbarkeit ohne keyword "Package". Gibst du gar keine Sichtbarkeit (explizit) an, so ist es nur innerhalb des aktuellen Packages sichtbar. Egal ob Superclass, Subclass, andere Klasse, ...

 

[Joew0815]

@xyz: Ich glaube du verstehst Vererbung ein bisschen falsch: Wenn ich eine Unterklasse erstelle, wird da nichts von oben in die Unterklasse "herunterkopiert" - und demnach auch nichts ausgelassen. Alles was vorher in der Oberklasse drin war bleibt dort drin, auch wenn ich eine Unterklasse erstelle. Die Unterklasse hat dann trotzdem alle Eigenschaften und Methoden aus allen ihren Oberklassen (Konstruktoren ausgenommen, die sind dann für immer weg).

Wieso nicht, Vererbung hat ja nicht direkt mit der Sichtbarkeit zu tun.

Ach, plötzlich...

 

[Noctarius]

Ach, plötzlich...

Dann les noch mal genau was du geschrieben hast als ich zugestimmt habe und dann weißt du, dass du dich da definitiv (selbst wenn du das richtige meintest) doof ausgedrückt hast.

 

[Java.xzy]

@xyz: Ich glaube du verstehst Vererbung ein bisschen falsch: Wenn ich eine Unterklasse erstelle, wird da nichts von oben in die Unterklasse "herunterkopiert"

Ich glaube, du hast mir damit gerade ein bisschen die Augen geöffnet, sofern ich es richtig verstanden habe.

Also kann man sagen, dass wenn in der Literatur von Vererbung gesprochen wird, das ganze eigentlich nur auf die Sichtbarkeit bezogen ist?

Also Kindklasse erbt von Elternklasse Attribut X.
In Wirklichkeit hat die kindklasse aber kein X, sondern benutzt einfach das X der Elternklasse - auch wenn ich ein Objekt des Kindes erstellt habe und nicht der Elternklasse (wegen "ist-ein" habe ic hes wohl doch, aber egal).

Also wenn man strikt wäre müsste man sagen, vererbt wird eigentlich garnichts - außer Regeln für die Sichtbarkeit auf Superklassen.

 

[0x7F800000]

Also wenn man strikt wäre müsste man sagen, vererbt wird eigentlich garnichts - außer Regeln für die Sichtbarkeit auf Superklassen.

Vielleicht sollte man einfach weniger labern, und mehr java schreiben... :autsch: Ist doch egal wie man's nennt, Vererbung ist einfach Vererbung, wenn man's 500 Mal gemacht hat, rafft man's, oder halt nicht... Oder muss man alles unbedingt auf deutsch sagen, damit's klar wird?

 

[Marco13]

Der abgedriftete Teil der Diskussion klingt mir (für diese Uhrzeit) zu Wortklauberisch.

Nochmal die Eingangsfrage:

Wie sieht die Verwendung allerdings intern in der Klasse aus? Hier kann ich ja problemlos auf die privaten Attribute zugreifen, ich könnte aber genau so gut deren getter und setter verwenden, wie es alle externen Aufrufer auch machen.

Was ist besser?

Eigentlich wäre es theoretisch sauberer, immer und überall die entsprechenden Methoden zu verwenden. Ich hatte da auch schonmal in http://www.java-forum.org/allgemeine-java-themen/44575-staerkerer-access-modifier-private.html dazu gesagt (so einer wäre nämlich notwendig, um dieses "saubere" Verhalten zu erzwingen - weil wenn man es nicht erzwingt, dann macht es auch niemand).

Das ist aber nur theoretisch. Praktisch macht das wohl niemand, weil es einfach "umständlich" ist. Wenn man die Wahl hat, sowas zu schreiben wie
setCounter(getCounter()+1);
aber stattdessen auch
counter++;
schreiben kann, macht man natürlich letzteres. Und wenn nun Minesweeper gestartet werden soll, sobald der Counter einen Wert >10 hat, muss man an ALLEN Stellen (nur innerhalb der Klasse, aber dort überall) nachsehen, ob und wie der Counter verändert wird - und unter anderem (!) mit diesem Argument sind ja die set/get-Methoden an sich begründet.

Wenn in einer Sprache das Uniform access principle - Wikipedia, the free encyclopedia umgesetzt ist, erübrigt sich das. Aber so. Naja.

 

[citizen_erased]

public class Vererbung {
	
	public static void main(String[] args) {
		Oberklasse oberklasse = new Oberklasse();
		Unterklasse unterklasse = new Unterklasse();
		
		oberklasse.setPrivateMember(123); 
		unterklasse.setPrivateMember(456); 
		
		System.out.println("oberklasse: "+oberklasse.getPrivateMember());  // Ausgabe: 123
		System.out.println("unterklasse: "+unterklasse.getPrivateMember()); // Ausgabe: 456
		
	}
}
	
class Oberklasse {
	
	private int privateMember;

	public void setPrivateMember(int newValue) {
		this.privateMember = newValue;
	}	
	
	protected int getPrivateMember() {
		return privateMember;
	}
}

class Unterklasse extends Oberklasse {
	
          public Unterklasse() {
        	 // this.privateMember = 0;  <- Kein Zugriff auf privateMember
          }
}

Kurze Erläuterung:
Die Variable "privateMember" der Klasse "Oberklasse" ist nur in Objekten der Klasse "Oberklasse" sichtbar.
Die Unterklasse "Unterklasse" kann nicht auf die Variable "privateMember" zugreifen (siehe Konstruktor "Unterklasse"), allerdings auf die Methoden "setPrivateMember" und "getPrivateMember" (siehe main-Methode der Klasse "Vererbung").
Das Beispiel erläutert, dass Objekte der Klasse "Unterklasse" dennoch über die geerbten Funktionalitäten einen eigenen Wert für die Variable "privateMember" besitzen können. "Unterklasse" erbt set- und get-Methode von Oberklassen und hat damit Zugriff auf die eigene (ebenfalls veerbte) Variable "privateMember"

 

[Sonecc]

und das soll uns was sagen?

außer, dass man über methoden die privaten Mitglieder der superklasse verändern kann?
Was schon mehrfach hier gesagt wurde?
Was von Sun bestätigt ist?

 

[0x7F800000]

*abonemment lösch* :autsch:

 

[citizen_erased]

und das soll uns was sagen?

außer, dass man über methoden die privaten Mitglieder der superklasse verändern kann?
Was schon mehrfach hier gesagt wurde?
Was von Sun bestätigt ist?

vielleicht ist etwas code hilfreich. und - wie du schon gesagt hast - wurde schon alles gesagt, weshalb ich auch keine weiteren kommentare hinzufügen wollte.

 

[Sonecc]

meine flapsigen fragen sollten darauf hinweisen, dass so komplett ohne kommentar der code nicht weiterhilft^^
er beschreibt im prinzip nur die Frage des TO

 

[citizen_erased]

du magst recht haben, ausserdem habe ich fast den eindruck, ich habe das in den falschen thread gepostet? mein fehler!! zuviele browsertabs sind nicht gut. am liebsten würde ich das wieder löschen...

 

[Sonecc]

warum? dein Code bringt die frage auf den Punkt So kann man wenigstens genau erklären, wo das Verständnissproblem liegt.

 

[citizen_erased]

ok, habe mal etwas Text ergänzt