Designfrage bei Klassemodellierung

[r2c2]

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

[s.h.a.r.k]

Es sind reine repräsentative Klasse, die noch um Controller angereichert werden. Aber damit hat es wenig zu tun. Es geht eigentlich nur darum, ob hier eine so präzise Vererbung sinnvoll ist, oder eben eher wenige Klassen mit mehr Optionen.

Ich könnte ja alternativ zu den obigen Klassen folgendes konstruieren:

Delphi-Quellcode:

Request = class
  Typ : Element of (Neu, Ändern, Benutzer löschen)
  Rollen : List of Rolle
  ZusatzOption : Boolean
  PflichtWennZusatzOptionTrueA : String
  PflichtWennZusatzOptionTrueA : Integer

Das wäre dann eine sehr fette Klasse, von der ich halt nicht immer alle Eigenschaften benötige, abhängig vom Typ. Ich erwähne hiermit ausdrücklich, dass das nun ein sehr krasses Beispiel ist, da ich nun alles erdenkliche in eine Klasse gepackt habe. Man kann die sieben obigen Klassen ja auch auf drei komprimieren, aber mit dem gleichen Effekt.

[Alaitoc]

Ich versuche meistens meine Klassen immer so zu stricken, dass nur Eigenschaften o.Ä. in der Klasse sind die ich benötige. Wobei ich da wohl auch mal von abweiche, jedoch meistens lieber ein paar mehr Klassen. Einfach nur wegen der Übersichtlichkeit und der Anpassbarkeit.

Am Besten ein Klassendiagramm erstellen und überlegen was sich noch ändern könnte, bzw. worauf man gefasst sein müsste...natürlich auch wieder Aufwand ^^

MfG Alaitoc

[s.h.a.r.k]

Zitat von Alaitoc:

Ich versuche meistens meine Klassen immer so zu stricken, dass nur Eigenschaften o.Ä. in der Klasse sind die ich benötige. Wobei ich da wohl auch mal von abweiche, jedoch meistens lieber ein paar mehr Klassen. Einfach nur wegen der Übersichtlichkeit und der Anpassbarkeit.

Am Besten ein Klassendiagramm erstellen und überlegen was sich noch ändern könnte, bzw. worauf man gefasst sein müsste...natürlich auch wieder Aufwand ^^

MfG Alaitoc

Hatte schon so ziemlich erwartet, dass ich das höre. Aber ich lasse mir bei sowas dann doch gerne mal was anderes samt passender Argumentation erzählen, da dies bzgl. wohl noch nicht sooo weise bin Ist immer interessant was wer wie machen würde...

Muss mir jetzt unbedingt mal das Clean Code Buch durchlesen -- ich hab es schon ewig daheim liegen und bin noch gar nicht dazu gekommen da mal rein zu schauen...

[Alaitoc]

Ich hatte gewissermaßen Glück und bei mir wurde in der Ausbildung viel wert auf sowas gelegt. Wobei ich gar nicht wissen will was ich noch alles falsch mache :3

Was man zumindest immer bei sich liegen haben sollte ist ein Buch mit Entwurfsmustern, finde ich äußerst prakisch

MfG Alaitoc