Sehr interessante Frage.
Ich geh mal davon aus, dass deine Request-Klasse die Anträge nur repräsentieren und nicht darstellen, also insbesondere keine Formulare sind. Dann würde ich das so machen:
- TRequest ist ne Klasse.
- Neu, ändern und löschen sind Aktionen, die zu nem Aufzählungstypen werden. Die Wahrscheinlichkeit, dass da noch mehr dazu kommt, als diese drei ist gering (
CRUD). Und effektiv handelt es sich hier ja wirklich nur um ein Datum und nicht um eine anderes Konzept. Kann aber sein, dass ich das falsch verstehe. Gibt es konzeptionelle Unterschiede?
- Es könnten Änderungen an den Feldern, Zusatzangaben, etc. geben. Deshalb solltest du hier eher Klassen nehmen. Entweder Subklassen oder Kompositionsklassen.
- Sollte sich ein Löschantrag anders verhalten als ein Neu-Antrag, hast qu quasi das Problem, dass du zwei parallele Klassenhierarchien bräuchtest. Einmal die Hierarchie über die Aktion (Neu, Ändern, Löschen) und einmal über die Zusatzeigenschaften. Das ist quasi das Problem, das du in deinem ersten Beitrag darstellst. Die Lösung liegt, wie Stevie schon angedeutet hat, in der Komposition. Allerdings heißt Komposition nicht immer gleich Strategy-Pattern. Hier wäre das
IMHO eher ne
Brdige. Strukturell ist das aber ähnlich zur
Strategy und im Spezialfall, dass deine 3 Aktionen einfach separat siehst und nicht als Hierarchie (und zudem die zugehörigen Klassen zustandslos wären) hätten wir tatsächlich ne Strategy. Patterns fließen ineinander über.
mfg
Christian