Hallo Karl Heinz,
besten Dank für deine Anregungen.
> Nun eine Eigenschaft hat einen Namen und einen Wert. (Fuers
> erste. Da wird wahrscheinlich noch was dazu kommen. Zb.
> Wertebereich, Darstellungsform, etc.)
Genau, ich hab es auch tatsächlich schon mit Namen, Wert und
Wertebereich implementiert.
> class Eigenschaft
> class SetOfEigenschaften
> Tja. Und nachdem du das hast, verpasst Du jetzt jedem Tier
> so eine Eigenschaftsmenge:
Da besteht nur ein geringer Unterschied zu meiner Lösung, du bildest
erst Name-Wert-Paare, um die in einem Vektor aufzusammeln und bei mir
enthält "SetOfEigenschaften" halt mehrere Vektoren. Da aber
"SetOfEigenschaften" dies in sich kapselt, treten beide Versionen
nach außenhin gleich auf. Was halt statt Vektoren gleich noch möglich
wäre, ist eine Map mit dem Paar Name-Wert (bzw. statt des Wertes wieder
ein Verbund von Wert und Wertebereich etc.).
> Jedes Tier, dass davon ableitet, erbt automatisch
> ein SetOfEigenschaften, in dem es jede beliebige Information
> speichern kann.
Ja, nicht anders geht es meinen Dingen auch.
> Dein Dialog kuemmert sich dann nicht mehr um Tiere. Dein Dialog
> kriegt ein SetOfEigenschaften zur Verfuegung gestellt. In dem ...
Richtig, so handhabe ich es jetzt schon. Der Dialog bekommt nur das
Konstrukt mit den Parametern. Auf der Seite ist das ja auch alles schön
und gut. Die Klasse "SetOfEigenschaften" beinhaltet Accessoren die bei
Zugriff auf die Werte den Wertebereich testen. Unschön ist bei meiner
Konstruktion allerdings, dass die "Tiere" dynamisch in ihrem
Konstruktor das "SetOfEigenschaften" definieren, also Namen,
Defaultwerte und Wertebereich angeben. "SetOfEigenschaften" hat also
eine Zugriffsfunktion die dies erlaubt. Dann verhindert allerdings
nichts, dass der Dialog dies auch tut. Zur Zeit habe ich ein Flag
dafür, was nach Initialisierung gesetzt wird. Das ist halt eine Prüfung
zur Laufzeit die mir nicht gefällt, besser wäre eine Prüfung zur
Compile-Zeit, aber mir fällt nichts gescheites ein.
> Der wesentliche Unterschied: Du musst zunaechst mal eine
> Klasse aus Namen-Wert bauen und erst dann wird daraus ein
> vector aufgebaut. Nicht 2 vectoren in dem jeweils die Namen
> und die Werte gespeichert sind. Sowas bringt Dich auf lange Sicht
> um.
Der Unterschied ist mir klar und mir gefällt die Idee erst Paare zu
bilden auch besser :-), aber ein richtiges Problem kann ich nicht
erkennen, da das Ganze in einer einzigen Klasse gekapselt ist und das
Problem dort nicht hinaustreten kann...
Mein eigentliches Problem und die wahre Narretei an der Implentierung
ist aber das folgende: Historisch gewachsen sind die ganzen Klassen
ohne Dialoge (und deswegen suche ich ja jetzt das "Designpattern für
solche Fälle), haben also ihre Parameter in Form klassischer Variablen
(POD-typen) mit den üblichen Zugriffsmethoden. Dann kam die
Paramtersammlung für Dialoge hinzu und das Problem ist, dass jetzt
Informationen doppelt vorhanden sind. Dies wiederum erfordert, dass
vor und nach jedem Dialog die Daten übertragen werden. Das ist der
Schwachsinn, den ich nicht gleich behoben habe. Die traditionellen
Daten müssen weg, nur noch die Parametersammlung wird verwendet,
Accessoren müssen diese verwenden und alle Methoden selbst müssen auch
die Accessoren verwenden statt auf Interna direkt zugreifen zu können.
Viele Grüße
