Hallo,
ich habe den Artikel Why getter and setter methods are evil gelesen und kann nachvollziehen, dass es schlechte Praxis ist, intern verwendete Datentypen über get- und set-Methoden zugänglich zu machen. Der Autor argumentiert, dass dieses Muster nur für die Werkzeugunterstützung eingeführt, damit man etwa beim Zusammenklicken einer GUI gleich sieht, an welchen Parametern man drehen kann.
Der Autor bringt ein Beispiel, wo man statt "String getId()" lieber eine Methode implementieren soll, die das tut, was man sonst außerhalb mit dem Feld "login" tun würde, beispielsweise "drawYourself()", das die Darstellung übernimmt. Damit ist anderer Code nicht davon abhängig, dass die ID ein String ist, es könnte auch ein Foto oder sonstwas sein. Nun merkt er aber selbst an, dass er damit GUI-Code in sein Domänenmodell bringt, bestreitet aber sogleich, dass er das tatsächlich tut, weil die eigentliche Darstellung ja mit AWT oder Swing außerhalb stattfinden würde. Er schreibt, dass der das Problem mit möglicherweise wechselnden GUIs dadurch lösen könnte, dass er eine "give-me-a-JComponent-that-represents-your-identity class" einführt. Bloß damit wäre die eigentliche Klasse ja immer noch von z. B. Swing abhängig, was ich nicht besonders schön finde.
Wenn ich an verschiedene Frameworks wie Spring MVC oder Wicket denke, fällt mir kaum ein sinnvoller weg ein, wie man die Darstellung der Klasse überlassen sollte. In Wicket würde man wohl eine Wicket-Komponente zurückegeben. Aber in Spring MVC könnte man keine GUI-Komponente zurückgeben, man müsste wohl HTML erzeugen. Aber selbst wenn man das täte, bliebe das Problem, wie die Werte aus einem Formular dann zurück in das Objekt kommen?
Bei dem klassischen Fall mit Gettern und Settern, werden z. B. in Wicket die Zugriffsmethoden der jeweiligen Felder aufgerufen, um die Formularwerte zu übernehmen. Wie sollte das ohne Getter und Setter laufen?
Der Autor bringt noch Reflection und die Annotation @Property (gibt es die offiziell?) ins Spiel. D.h. man könnte alle Felder "private" machen und wenn ein Formular abgesendet wird, die Daten per Reflection direkt in die Felder schreiben. Bloß das ändert an dem Problem ja nichts. Wenn ein Feld ein boolean ist, muss aus dem Formular auch ein boolean kommen. Und wenn das boolean-Feld irgendwann in eine Enumeration umgewandelt wird, muss man die Stelle wo der Wert gesetzt wird, genauso ändern, wie man es mit einem Setter tun müsste.
Wie würde man das in SmallTalk machen? Ich habe gelesen, da bräucht men sowas wie Getter und Setter dank des Nachrichtenkonzepts nicht. Hier ist ein Beispiel in Ruby, aber beantwortet nicht die Frage, wie Werte gesetzt werden:
http://www.java-forum.org/allgemeine-java-themen/47023-getter-und-setter.html
So reizvoll ich die Idee finde, ohne Getter und Setter zu programmieren, mir fällt kein vernünftiger Weg ein, das tatsächlich zu tun. Seht ihr einen Weg?
ich habe den Artikel Why getter and setter methods are evil gelesen und kann nachvollziehen, dass es schlechte Praxis ist, intern verwendete Datentypen über get- und set-Methoden zugänglich zu machen. Der Autor argumentiert, dass dieses Muster nur für die Werkzeugunterstützung eingeführt, damit man etwa beim Zusammenklicken einer GUI gleich sieht, an welchen Parametern man drehen kann.
Der Autor bringt ein Beispiel, wo man statt "String getId()" lieber eine Methode implementieren soll, die das tut, was man sonst außerhalb mit dem Feld "login" tun würde, beispielsweise "drawYourself()", das die Darstellung übernimmt. Damit ist anderer Code nicht davon abhängig, dass die ID ein String ist, es könnte auch ein Foto oder sonstwas sein. Nun merkt er aber selbst an, dass er damit GUI-Code in sein Domänenmodell bringt, bestreitet aber sogleich, dass er das tatsächlich tut, weil die eigentliche Darstellung ja mit AWT oder Swing außerhalb stattfinden würde. Er schreibt, dass der das Problem mit möglicherweise wechselnden GUIs dadurch lösen könnte, dass er eine "give-me-a-JComponent-that-represents-your-identity class" einführt. Bloß damit wäre die eigentliche Klasse ja immer noch von z. B. Swing abhängig, was ich nicht besonders schön finde.
Wenn ich an verschiedene Frameworks wie Spring MVC oder Wicket denke, fällt mir kaum ein sinnvoller weg ein, wie man die Darstellung der Klasse überlassen sollte. In Wicket würde man wohl eine Wicket-Komponente zurückegeben. Aber in Spring MVC könnte man keine GUI-Komponente zurückgeben, man müsste wohl HTML erzeugen. Aber selbst wenn man das täte, bliebe das Problem, wie die Werte aus einem Formular dann zurück in das Objekt kommen?
Bei dem klassischen Fall mit Gettern und Settern, werden z. B. in Wicket die Zugriffsmethoden der jeweiligen Felder aufgerufen, um die Formularwerte zu übernehmen. Wie sollte das ohne Getter und Setter laufen?
Code:
public class Person {
private String nachname, vorname, email, strasse, plz, ort;
public String getNachname() {return nachname;}
public void setNachname(String nachname) {this.nachname = nachname}
// usw ...
}Der Autor bringt noch Reflection und die Annotation @Property (gibt es die offiziell?) ins Spiel. D.h. man könnte alle Felder "private" machen und wenn ein Formular abgesendet wird, die Daten per Reflection direkt in die Felder schreiben. Bloß das ändert an dem Problem ja nichts. Wenn ein Feld ein boolean ist, muss aus dem Formular auch ein boolean kommen. Und wenn das boolean-Feld irgendwann in eine Enumeration umgewandelt wird, muss man die Stelle wo der Wert gesetzt wird, genauso ändern, wie man es mit einem Setter tun müsste.
Wie würde man das in SmallTalk machen? Ich habe gelesen, da bräucht men sowas wie Getter und Setter dank des Nachrichtenkonzepts nicht. Hier ist ein Beispiel in Ruby, aber beantwortet nicht die Frage, wie Werte gesetzt werden:
http://www.java-forum.org/allgemeine-java-themen/47023-getter-und-setter.html
So reizvoll ich die Idee finde, ohne Getter und Setter zu programmieren, mir fällt kein vernünftiger Weg ein, das tatsächlich zu tun. Seht ihr einen Weg?
[/DUKE]
