Ich denke dass "nat" auf der richtigen Spur ist.
Eigentlich benötigt man eine Proxy-Klasse, die einen Cache benützt.
Und es gibt noch ein Dateninterface; also die Schnittstelle über die Daten geholt werden.
Ein ganz einfaches Interface sieht so z.B. so aus:
Delphi-Quellcode:
IDataInterface = interface
// liefert einen Wert anhand eines Schlüssel
function GetData(key:string):string;
end;
Das heisst jetzt nicht, dass man wirklich Interfaces verwenden muss; es dient nur zur gedanklichen Vorstellung.
Dann sähe das "Objektschaltbild" so aus:
Code:
Konsument <-- Datenobjekt
Jetzt schalten wir ein Proxyobjekt zwischen den Konsument und das Datenobjekt.
Das Proxyobjekt hat die gleiche Schnittstelle wie das Datenobjekt.
Sowohl das Proxyobjekt als auch das Datenobjekt implementieren die gleiche Schnittstelle.
Der Konsument merkt also gar nicht, ob es direkt auf dem Datenobjekt arbeitet oder mit dem Proxy redet:
Code:
Konsument <-- Proxy <-- Datenobjekt
|
|
Cache
Die Proxyklasse erhält im Konstruktor das Datenobjekt übergeben.
Der Datenfluss durch den Proxy geht im Bild oben nur in eine Richtung.
Man kann den Proxy aber auch so bauen, dass auch Daten vom Konsument zum Datenobjekt fliesen.
Code:
Konsument/Produzent <--> Proxy <--> Datenobjekt
|
|
Cache
Hierbei gibt es mindestens drei Varianten:
1.) Der Proxy schiebt die Daten nur in den Cache und markiert sie (dirty bit) als verändert.
Später werden alle veränderten Daten zum Datenobjekt zurückgeschrieben
2.) Der Proxy schreibt direkt durch zum Datenobjekt (write-through)
3.) Der Proxy schreibt direkt durch zum Datenobjekt und zusätzlich in den Cache
Man braucht so mehr Klassen, aber dürfte so kein Problem sein, den Proxy zur Laufzeit
in den Transparentmode zu versetzen.
Vielleicht arbeitet auch irgend jemand am Proxy vorbei und es könnte nötig werden den Cache zu löschen,
weil die Daten nicht mehr aktuell sind.
Zitat
Baum-Darstellung
