Member-Variablen mit settern setzten

Luk10

Top Contributor
Grüße,

Ich lese des öfteren, dass Klasseneigene Membervariablen mit Settern gesetzt werden, anstatt sie direkt zu setzten. Beispiel:

Java:
class Foo {
  
  private int bar;

  public void setBar(int bar) {
    this.bar = bar;
  }

  public void doSomething(int a) {
    setBar(a);
  }

}

Hat das einen Sinn, oder ist es einfach nur ein anderer "Coding"-Stil? Was haltet ihr davon gegenüber der normalen Zuweisung?

Danke,
-Luk10-
 
Man sollte nie* direkt auf Member zugreifen, sondern immer per Getter und Setter. Sei es, dass du irgendwann Logging, Access Restrictions, Validierungen oder was auch immer einbauen willst.

*es gibt natürlich Situationen, in denen innerhalb der Klasse ein Feld irgendwie speziell gesetzt werden muss, bei dem man die Validierung o.ä. im Setter umgehen will. Aber das sind Ausnahmefälle.
 
Wirklich? Selbst wenn es in der selben Klasse ist? Ich meine, die Variablen sind doch
Code:
private
...

Kann mir jemand den genauen Unterschied zwischen "Instanzvariablen" und "Membervariablen" erklären, bzw was das oben im Beispiel ist.

Danke,
-Luk10-
 
Membervariable ist ein Synonym für Instanvariable...

Und ja, man sollte immer mit Gettern und Settern arbeiten. Am Anfang um sich daran zu gewöhnen (auch wenn es nicht unbedingt relevant ist fuer kleine Programme) weil es später aus verschiedenen Gründen relevant sein wird:

- Die Variable darf nur aus einem bestimmten Zahlenbereich sein.
- Es wird auf anderen Wegen auf die zu ändernden/empfangenden Daten zu gegriffen
(z.B. über eine Datenbank oder eine "Live-Anwendung" ).
- Wenn andere Leute mit an einem Projekt arbeiten, stellt man ihnen dadurch diese Methoden zur
Verfügung, damit sie bestimmte Werte einfach ändern können und für einen selbst sichergestellt ist,
dass die Variablen nicht von Außen z.B. auf ein im ungültigen Wertebereich liegenden Wert geändert
werden oder ein null-Objekt erhalten.
 
Zuletzt bearbeitet:
Also schreibt man auch

Java:
public void foo() {
  setBar(bar + 5);
}

wenn man bar um 5 erhöhen will ... das erscheint mir wahnsinnig umständlich und aufwändig ...

EDIT: aufwändig
 
Zuletzt bearbeitet:
Innerhalb einer Klasse würde ich das nicht unbedingt tun. Kann nicht schaden und ist gut, aber muss nicht soo dringend, weil man das meist überblicken kann.
Aus Performancegründen kanns bei bestimmten Klassen auch Ausnahmen geben, was die Setter angeht. Aber sowas macht man besser, wenn man weiß, was man tut 😉 (Ein Beispiel wäre die Vectorklasse in der jMonkeyEngine. Davon die Komponenten auszulesen passiert in einem Spiel in einer Sekunde viele tausende Mal)
 
In der Regel werden die Instanzvariablen über den Konstruktor gesetzt und die Getter- und Setter werden nur noch für diejenigen Variablen erzeugt, die auch gelesen resp. verändert werden müssen/dürfen.
 
In der Regel werden die Instanzvariablen über den Konstruktor gesetzt und die Getter- und Setter werden nur noch für diejenigen Variablen erzeugt, die auch gelesen resp. verändert werden müssen/dürfen.

selbst da bietet es sich an, mit einem setter zu arbeiten (dann halt private), weil dann auch diese Zuweisung prezisiert/geprüft/berechnet werden kann und spätere Änderungen aus dem Konstruktor verschwinden.
 
Zuletzt bearbeitet von einem Moderator:
Also schreibt man auch
Java:
public void foo() {
  setBar(bar + 5);
}
wenn man bar um 5 erhöhen will ... das erscheint mir wahnsinnig umständlich und aufwändig ...

Eigentlich wäre das dann
[c]setBar(getBar()+5);[/c]

Und ja, das ist umständlich. So umständlich, dass ich es in der Praxis noch nicht gesehen habe. Das Argument, dass bei den 1000000 Memberzugriffen, die man schreibt, irgendwann mal 5 Zugriffe auf 1 Member über setter gemacht werden müssen, ist ziemlich schwach. Eigentlich wäre es schön, das immer so zu machen, schon wegen des Uniform access principle - Wikipedia, the free encyclopedia , aber ... das gibt es eben in Java nicht. Für alles andere bräuchte man einen http://www.java-forum.org/allgemeine-java-themen/44575-staerkerer-access-modifier-private.html ... 😉
 

Zurück
Oben