Objekt mehrfach speichern: Hilfe für OO-Konzept, Pattern.

[alzaimar]

Hallo Dax, moin marabu,

vielen Dank für Eure Antworten.

Das Observer-Pattern entspricht in etwa meiner Idee von den Engines. Falls ich das Pattern und deine Demo richtig deute, müsste ich die Speicherlogik, also welche Kundendaten konkret abzuspeichern sind, in jedem Observer implementieren. Und genau das mißfällt mir, da ich jeden Observer anfassen muss, wenn sich die Struktur meines Stammobjektes ändert. Das ist eine Fehlerquelle, da ich jeden Observer explizit durchtesten muss, und die Wahrscheinlichkeit besteht, das ich mich irgendwo verhaspelt, oder bei einer Änderung einen Observer vergessen habe.

Bei der Idee von DAX passiert mir das nicht. Sofern ich einmalig nachgewiesen habe, das die grundlegenden I/O-Funktionen (ReadXXXX, WriteXXXX) korrekt implementiert sind, nehme ich Änderungen wirklich nur an einer zentralen Stelle vor.

Ich benötige dann noch einen Dispatcher, der die Read/WriteXXXXX-Aufrufe an die angeschlossenen Engines verteilt.

Doch, das ginge:

TAbstractEngine - definiert die Read/Write-Operationen
TDispachingEngine - pflegt eine Liste von TAbstractEngines, an die die Read/Write-Operationen verteilt werden. Andere Engines melden sich an (dann werden Sie bei der Verteilung berücksichtigt), und wieder ab.

TDatabaseEngine - implementiert eine TAbstractEngine für Datenbanken
TActiveDirectoryEngine - implementiert eine TAbstractEngine für AD
... usw

Ich instantiiere die benötigten Engines, und registriere sie in der TDispatchingEngine.
Das Kundenobjekt wickelt seine I/O-Operationen über die TDispatchingEngine ab.

Was haltet Ihr davon?