Ich tue mich schwer das Beispiel zu verstehen.
Element sind doch einfach nur Eigenschaften (Daten), keine Objekt, das etwas tut. Ich verstehe auch nicht, weshalb es TMonster/IMonster überhaupt kennen muss. Machen tut doch das Monster. Es guckt auf sein Feld
Referenz
oder
Element
und handelt entsprechend.
Geht es dir darum, in Monster direkt darauf zu reagieren, wenn man im Code z.B. sagt
meinMonster.Referenz.Farbe := blau
? Dann würde man der Referenz im Konstruktor wohl einen Callback mitgeben den es aufrufen soll, wenn auf ihm was geändert wird. Oder es hat eine Event-Variable
OnChange
an die sich das Monster binden kann, um darauf zu reagieren dass in Referenz sich etwas geändert hat.
Ein "Real World Example" ist wohl z.B.
meinLabel.Font.Size := xx
. Da ist das auch so gelöst.
Klingt kompliziert? Ist es auch. Ich finde das Overkill. Und das hängt mit diesem Property-Gefummel zusammen, gegen das ich nicht müde werde zu wettern, aber damit stehe ich hier im Delphi-Forum eher alleine da.
Wie würde ich es machen?
- Element ist ein Record mit Feldern "Größe", "Farbe" usw.
- Element bekommt noch eine Operator-Überladung sodass ich z.B. sagen kann if elementNeu = elementAlt then ...
- Ich gebe IMonster nur ein getElement(): TElement und setElement(const element: TElement)
- In setElement(..) wird geprüft ob sich element überhaupt verändert hat, und wenn ja, dann tu etwas (z.B. zeichne dich neu)
Ja, statt
meinMonster.Referenz.Farbe := blau
tippe ich jetzt
Delphi-Quellcode:
referenz := meinMonster.getReferenz();
referenz.farbe := blau;
meinMonster.setReferenz(referenz);
Hebt sich aber auch schon wieder auf, wenn ich z.B. nicht nur Farbe, sondern auch Größe anpassen will. Ja, es sind ein paar Buchstaben mehr zu tippen wenn man was ändert. Aber an den anderen Stellen wird es so viel simpler: Die Daten sind an einem Platz, und sind wirklich nur Daten, und ich brauche keine Callbacks für Änderungen "eins weiter unten".