Zugriff auf Klassenvariablen NUR mit get/set Methoden?

[XBreed]

Hallo Leute,

die variablen die unterhalb des Klassennamen stehen sprich Klassenvariablen, darf man auf diese nur mit get/set Methoden zugreifen? gibt es eine Möglichkeit in Eclipse 3.3 mir 20 dieser Methoden automatisch generieren zu lassen wenn ich z.B. 20 dieser variablen habe z.B.:

private String name;
private String farbe;
usw...

dies soll automatisch generiert werden:

getName();
setName();
getFarbe();
setFarbe();
usw.

geht das?

 

[maki]

Rechtsklick in den Quellcode -> Source -> Generate Getters and Setters

 

[XBreed]

supi!

 

[JavaFred]

die variablen die unterhalb des Klassennamen stehen sprich Klassenvariablen, darf man auf diese nur mit get/set Methoden zugreifen?

Wenn sie als private oder protected deklariert sind: ja.

Falls Deine setter nichts anderes machen, als den übergebenen Parameter der Exemplarvariablen zuzuweisen (also ohne irgendeine Form der Überprüfung), dann kannst Du die Exemplarvariablen aber auch einfach public machen.

Was sind denn das für Objekte? Bei einfachen Wertsammlungen ohne viel Funktionalität (getter und setter sind ein Indiz dafür) würde ich an Deiner Stelle die Exemplarvariablen public final machen und deren Werte im Konstruktor setzen. Das geht allerdings nur dann, wenn die freigegebenen Objekte immutable sind (wie etwa String, einen String kann man ja nicht verändern).

 

[maki]

Falls Deine setter nichts anderes machen, als den übergebenen Parameter der Exemplarvariablen zuzuweisen (also ohne irgendeine Form der Überprüfung), dann kannst Du die Exemplarvariablen aber auch einfach public machen.

Nana, wer wird denn Anfängern gleich schlechte Pratiken empfehlen?

 

[JavaFred]

Setter sind dazu da, um Invarianten sicherzustellen. Wenn es keine gibt, sind setter sinlos.

 

[maki]

Setter sind dazu da, um Invarianten sicherzustellen. Wenn es keine gibt, sind setter sinlos.

Nö, manchmal sind sie einfach nötig, durch Konvention, zB JavaBeans und damit alles was JavaBeans nutzt, und das sind einige Frameworks.

Ansonsten ist es eher von Nachteil, keine konsequente Linie zu haben und damit konistente Schnittstellen, führt zu mehr Verwirrung, als wenn ich immer per Setter setze und per Getter zugreife("Wie war das bei der Property dieser Klasse doch gleich?").
Alles in allem schlechter Stil.

 

[JavaFred]

Das mit JavaBeans mag stimmen, da kenne ich mich nicht aus.

These: Eine große Anzahl von set-Methoden ist meistens ein Anzeichen für schlechtes OO-Design.

 

[maki]

These: Eine große Anzahl von set-Methoden ist meistens ein Anzeichen für schlechtes OO-Design.

Hmm, sehe ich anders.
POJOS brauchen auch getter und setter für alles.

Dazu kommt, wenn ich immer Setter und Getter verwende, habe ich eine echte (und konsistente) Schnittstelle, die Implementierung kann sich über die Zeit hinweg ändern, zB sollen die Parameter irgendwann geprüft werden, um inkonsistente Objektezustände zu verhindern.
Mit Settern kein Problem, die Änderung bekommt keiner mit.
Ohne Setter sieht die Sache ganz anders aus, da muss jede Zeile Code, welche das Attríbut direkt ändert, angepasst werden.

Alles in allem halte ich Setter und Getter für "objektorientierter" als public Attribute, und dann war da ja noch was mit "Information Hiding".