Wann machen 'tagged'-accessor sinn?

[fork]

Moin,

In den meisten faellen schreibt man sich ja simple getter und setter nach dem schema.

Code: Alles auswählen

<type> get<Name>();
void set<Name>(<type>);

Manchmal stosse ich aber auch ueber 'tagged'-accessors - so nenne ich sie zumindest. Hat dieses pattern nen "richtigen" namen, dann verrated ihn mir bitte.
Am besten geht wie alles mit 'nem Beispiel:

Code: Alles auswählen

		Calendar c = GregorianCalendar.getInstance();
		int hour = c.get(Calendar.HOUR);
		c.set(Calendar.YEAR, 2012);
		

Wie man unschwer erkennen kann, unsre allgegenwaertige Lieblingssprache Java :mrgreen: :mrgreen: :mrgreen:
Funktionier'n tut das Patter natuerlich nur, wenn alle Elemente vom selben Typ (hier int) sind.

Findet ihr dieses Pattern sinnvoll, schonmal implementiert?
Am sinnvollsten waere es, wie auch in Calendar, wenn alle member vom selben Typ sind - es also keine (notwendigen) Ausnahmen gibt, imo.

[Chromanoid]

Ich denke das ist vor allem für Wertkompositionen interessant, die mit einem Muster formatiert als Text ausgegeben werden sollen bzw. je nach Ausprägung andere Interpretationen zulassen. Ich würde davon für den allg. Gebrauch abraten, da man mit dem Einhalten der Property-Syntax zum Einen keine unsinnigen Mehrdeutigkeiten einführt und zum Anderen diese Syntax wichtig für einen Gebrauch von Reflection ist bzw. die Nicht-Einhaltung eine sinnvolle automatisierte Auswertung erschwert.

Wenn man das ganze wirklich einsetzen will, dann sollte man wohl am besten enums als Spezifizierer verwenden, um zu verhindern, dass das ganze zu einem verkappten Key-Value-Store wird und schön statisch bleibt. Wenn das ganze zur Auswahl von Algorithmen für die Auswertung genutzt werden soll, empfiehlt sich vielleicht eher das Strategy-Entwurfsmuster.

[kaiserludi]

Ich finde das eher unschön, denn du musst ja c.get(Calendar.TIPPFEHLER) dann gesondert über einen intern default-Case zur Laufzeit als Fehler behandeln. Da ist es mir lieber, wenn bereits der Compiler meckert, dass er den Methodennamen des getters nicht kennt.

[simbad]

Na ich habe sowas ähnliches mal implementiert.
Eine Ansammlung von key-value pairs, bei denen ich aber auf eine std:map verzichten wollte, da die Felder nach einem sehr merkwürdigen schema serialisiert werden mussten.
Um das dann noch automatisch testen zu können, mit dem serialisieren und de-serialisieren testen und sowas alles, habe ich also die Feldselektion über den Namen und über einen Enumerator realisiert. Der tiefere Sinn dahinter ergibt sich eigentlich aus der Summe der Anforderungen.

Das ganze war eine Client-Server Konstellation, bei der der Server auch key-value pairs schicken kann, die der Client nicht kennt. Es musste also eh eine Validierung stattfinden, damit man im Client eine entsprechende Warning ausgeben kann.

Hinzu kam, das manche Felder optional waren und manche nicht. Auch gab es einen Feldtypen beim Transport vom Client->Server bei dem TRUE durch die Anwesenheit des Keys im Datenstrom dargestellt wurde. Boolean-Felder gab es auch noch, da hatte man dann key-"true" und key-"false" im Datenstrom.

Ich hatte einfach das Gefühl das es so am sinnvollsten ist.

So ist es übrigens in den meisten Fällen wenn Design-Entscheidungen zu treffen sind. Man muss die Summe der Anforderungen betrachten und erhält in vielen Fällen nur noch eine recht kleine Menge von möglichen Varianten für die Realisierung. Und ab da zählen dann persönliche vorlieben. :)