Zitat:
Eigentlich muss eine Klasse, die Spieler oder Mannschaften verwaltet, gar nicht wissen, dass diese in
XML-dateien gespeichert werden.
Ja, das habe ich schon so gelöst (hatte die Beschreibung etwas vereinfacht). Die Methoden der
DC´s greifen halt über Read- und Write-Funktionen auf
XML-Knoten zu.
Nein, hast du nicht. Allein schon die Tatsache, dass deine Klassen das
XMl-Zeug benutzen, koppelt sie an
XML. Stell dir vor du willst jetzt statt
XML die Daten in ne Datenbank schreiben. Oder in nem Textformat speichern. Oder übers Netzwerk schicken. Entkoppelt wäre es, wenn du dazu die Klassen nicht anfassen musst. Dazu werden die Klassen entweder von außen benutzt, d.h. die Daten extern gelesen (nicht so schön [1]) oder aber das Speichern wird über DependencyInjection gemacht (schön). Das sähe dann in etwa folgendermaßen aus:
Delphi-Quellcode:
// Pseudocode
TFoo = class
private
FMyWriter: TSomeWriter;
public
property MyWriter read FMyWriter write FMyWriter;
procedure Save();
begin
FMyWriter.Write(...);
...
end;
end;
TSomeWriter = class
procedure Write(); virtual; abstract;
end;
TXMLWriter = class(TSomeWrite)
...
end;
TDatabaseWriter = class(TSomeWrite)
...
end;
... grob skizziert ...
In TFoo steht rein gar nichts von
XMl. Man kann allein durch ersetzen der MyWriter-Eingeschaft aus nem Speichern in
XML eins in ne Datenbank machen. *Das* sind entkoppelte Objekte!
Zitat:
Zitat:
In OnPaint gehört nur Zeichencode.
Ok, ich she aber noch keine bessere Lösung. In den Daten gibt es irgendeine Änderung. Die sichbaren Controls werden darüber informiert. Wenn sie gerade unsichtbar oder in einem ausgeblendeten Formular oder register sind, ist denen die Änderung egal.
Das ist aber eine Optimierung von dir. Und die bringt dich in Teufels Küche. Soll ich nochmal Knuth zitieren? Klar verschenkt es Rechenzeit, wenn du alles aktualisierst und nicht nur das, was angezeigt wird. Allerdings sollte das normalerweise im vernachlässigbaren Bereich sein.
Was du hier aber machst, ist, inkonsistente Zustände erlauben. Eben die unsichtbaren Komponenten, die nicht aktualisiert werden. Sowas sollte man nur tun, wenn man *ganz* genau weiß, was man tut und einen guten Grund dazu hat.
Zitat:
Eine wirklich bessere Lösung fällt mir nicht ein, außer alle benötigten Daten direkt bei der Änderungsnachricht abzurufen und in Variablen abzulegen.
Nein, da verwechselst du was. Oder ich versteh dein Problem nicht ganz. Du musst da nix cachen. Es gibt zwei unterschiedliche Arten von Änderungen:
a) das Hinzufügen und Entfernen von Elementen ==> Diese Änderungen sollten direkt über ein Event in der
GUI mitgezogen werden. Sodass immer und unter jeden Umständen gilt, dass es keine überzähligen und keine Fehlenden
GUI-Elemente gibt.
b) das Ändern von irgendwelchen Werten. Die Werte können selbstverständlich in OnPaint gelesen werden. Das ist vollkommen unproblematisch. Nur solltest du in OnPaint niemals Konstruktoraufrufe oder ein "Free;" stehen haben.
Zitat:
1) dass alle zig000 Komponenten ständig die Daten abfragen, obwohl sie überhaupt nicht angezeigt werden
- Hast du wirklich Tausende von Objekten oder war das nur Übertreibung?
- Du musst selbstverständlich nicht die ganzen Wertänderungen nachziehen. Nur das Erzeugen und Freigeben von Listenelementen.
Zitat:
2) für alle "Felder" private Variablen zum Zwischenspeichern angelegt werden müssen (doppelte Datenhaltung)
Ein Caching kann aus Performancegründen zwar manchmal gut sein. Hier wäre es aber eher kontraproduktiv.
Zitat:
3) Für einige Komponentendarstellungen teilw. recht komplexe Datenermittlungen (Funktionen, Suchen, Berechnungen) möglich sein können. Das wäre unnötig, wenn die Komponente ja gar nicht angezeigt wird.
Es geht - wie schon erläutert - nicht um die Darstellung. Die kann und soll in OnPaint gemacht werden. Also nur dann, wenn auch wirklich gezeichnet wird.
[1] Weil das Objekt ja eigentlich selbst zu wissen hat, was von ihm gespeichert gehört. Man kann das auch mit Annotationen - oder wie heißen die Dinger in Delphi? Attribute glaub ich - festlegen und so generisch speichern. Dann ist gegen den externen zugriff wiederum nichts zu sagen.
mfg
Christian