OOP, Objekte neu laden, Komponenten aktualisieren

[stahli]

Zitat von DJ-SPM:

Kann aber auch vielleicht nur Einbildung sein, weil ich gerade nur die Hälfte verstanden habe

Ok, ich versuche es nochmal, wobei ich Dich auch nur halb verstehe.

Du musst unterscheiden, ob Dein Auto aufgelöst, durch ein neues ersetzt oder nur seine Farbe geändert wird.

Wenn ein Control (z.B. ein TPanelAuto) das Kennzeichen Deines Autos und dessen Farbe darstellen soll, würdest Du ihm dafür eine Autoinstanz (Autoobjekt "DataAuto" mit Kennzeichen und Farbwert) zuweisen. Wenn sich das TPanelAuto zeichnet (wann immer das auch ist), liest es aus dem Autoobjekt die benötigten Daten.

Das PanelAuto benutzt dafür die zugewiesene Speicheradresse. Wenn das Autoobjekt inzwischen aufgelöst wurde, bekommt PanelAuto das erst mal nicht mit. Es kann nicht einmal erkennen, ob das "DataAuto" überhaupt noch gültig ist.

Um das zu verwalten könnte man jedes erzeugte DataAuto-Objekt in eine Liste schreiben und beim Zerstören daraus entfernen. PanelAuto könnte nun nachschauen, od sein DataAuto noch in der Gültigkeitsliste enthalten ist.
Wenn nicht, wird der Pointer gleich genilt und ein leeres Panel gezeichnet.

Alternativ kann man Observer-Patterns nutzen. Das PanelAuto meldet sich beim DataAuto an (wird in einer internen Liste von DataAuto eingetragen). Wenn DataAuto aufgelöst wird, informiert es alle registrierten Objekte aus seiner internen Liste über sein Ende. PanelAuto würde dann erfahren, dass sein DataAuto nicht mehr existiert und den Pointer nilen (worauf hin es sich auch neu zeichnet und zwar "leer"). (PanelAuto muss sich natürlich auch wieder bei DataAuto abmelden, falls es früher aufgelöst oder ihm ein anderes DataAuto zugewiesen wird.)

Wird DataAuto nicht aufgelöst, sondern erhält nur eine andere Farbe, müsste eine entsprechende Nachricht verschickt werden, damit sich PanelAuto neu zeichnet.
Das kann ebenfalls über Observer realsiert werden oder einfacher (so habe ich das bisher gelöst) durch ein Invalidate aller erzeugten PanelAuto´s. Die zeichnen sich entsorechend dann neu, sofern sie sich in einem sichtbaren Bereich befinden. Hunderte PanelAuto´s auf geschlossenen Formularen werden natürlich nicht gezeichnet und bremsen das System somit auch nicht aus.

Wird dem PanelAuto ein anderes DataAuto zugewiesen, wird intern ebenfalls Invalidate aufgerufen und das PanelAuto zeichnet sich neu.


So funktioniert das im Grunde sehr gut (siehe mein Turnierprojekt).


Allerdings ist es so nicht möglich, die Daten in einem C/S-Projekt zu nutzen. Der Client kommt ja nicht ohne Weiteres an die Objekte.

Daher würde ich künftig lieber den TPanelAuto nicht ein TDataAuto zuweisen sondern eher eine AutoId. Dann kann es sich von einer zentralen Stelle über GetDataAuto(AutoId) ein DataAuto-Objekt (oder eine Schnittstelle) abrufen, damit arbeiten und dieses wieder verwerfen.
Wird eine ungültige AutoId übergeben, kommt einfach nil zurück und Zugriffe auf ungültige Objekte sind ausgeschlossen. Auch den Observerkram kann man sich (für diesen Bereich) sparen.

Wenn die zentrale Stelle in einem Server liegt, können sich mehrere Clients daraus bedienen (also die gleichen Autos anzeigen).
Die Clients vom Server aus über Änderungen zu informieren sollte nicht weiter schwierig sein. Schwieriger wird es wohl, vom Client Änderungen zum Server zu schicken (z.B. wenn ein Auto gelöscht, hinzugefügt oder verschoben wird) und Zugriffskonflikte zu verhindern.

Auf jeden Fall wird sich eine gute Modularisierung sehr bezahlt machen, da das Projekt dadurch besser wartbar sein wird. Mehr Tipparbeit (z.B. wegen der Objekte-Zentrale oder zu definierenden Schnittstellen) würde ich heute dafür hinnehmen.