Ich habe eine Klasse, sagen wir: Kunden.

Dieser Kunde muss in diversen Listen/DB gespeichert werden, also z.B.:

1. in einem DBMS
2. im ActiveDirectory
3. in der User-Liste eine Fremdapplikation

Ich habe leider bei den Patterns gefehlt, eigne mir also jetzt erst (10 Jahre später) das Wissen hierzu an, und daher würde ich gerne Anregungen haben, wie ich vom OO-Konzept so eine Geschichte am Besten angehen sollte.

Ich möchte ein gutes und wartbares Design sowohl hinsichtlich der Erweiterbarkeit der Stammklasse (hier: Kunde) als auch der Möglichkeiten der Speicherung implementieren.

Eine Möglichkeit wäre, wenn ich am der Klasse diverse 'I/O-Engines' registrieren kann. Wenn ich dann die 'Speichern' Methode des Kunden aufrufe, sollte dieser durch die Engines iterieren, und deren 'Speicher'-Methode aufrufen.

Dann hätte ich aber den Nachteil, das ich Erweiterungen an der Struktur des Kunden (z.B. soll seine Schuhgröße mit gespeichert werden), sowohl in der Kundenklasse, als auch an den Engines vornehmen müsste. Und das ist irgendwie blöd.

Frage: Hat jemand eine bessere Idee, sodaß ich -wenn auch nicht an einer einzigen Stelle- die Notwendigen Änderungen doch an einer Stelle im Code vornehmen kann..

Ideen?

Im Prinzip ist es ganz einfach Die Idee mit der Engineliste ist schon ok. Deine Engines lässt du nun jeweils ein Interface implementieren:

zusammenfalten · markieren

Delphi-Quellcode:

type
  IStorageEngine = interface
    procedure InitCustomer;

    procedure StoreInteger(i: Integer);
    procedure StoreString(s: string);

    function LoadInteger: Integer;
    function LoadString: string;

    // etc
  end;

Zustzlich verpasst du deiner Klasse jeweils eine Methode Store(IStorageEngine) und Load(IStorageEngine), die nichts weiter tun, als InitCustomer aufzurufen - um der Engine zu sagen, dass jetzt Zeugs für die Customer-Klasse ankommt - und dann alle Felder der Klasse in die IStorageEngine zu werfen oder sie wieder von dort zu laden. Damit sind die Engines generisch und du kannst sie für *jede* Klasse verwenden, die Logik zum speichern/laden ist an der selben Stelle wie die Felder und wenn du eine neue Storage Engine brauchst, bastelst du dir einfach eine schnieke Klasse und verpasst ihr das Interface.

Moin alzaimar,

für mich handelt es sich hier nicht um "ein" Objekt und "mehrere" Speichervorgänge, sondern um synchronisierte Objekte in lose gekoppelten Systemen. Ich würde das führende System festlegen und spontan das Observer-Pattern implementieren. Besonderes Augenmerk musst du dann dem Grad der Kopplung widmen.

Freundliche Grüße

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?

Zitat von alzaimar:

Was haltet Ihr davon?

Das klingt gut so wie du es sagst, allerdings würde ich die Engines eher über ein Interface definieren statt über eine abstrakte Klasse. So hast du die Möglichkeit, später z.B. auch COM-Objekte als Storage-Engines einzubinden.