[OOP-Struktur] Übergeordnete "Verwalter"-Klassen

[TheMiller]

Hallo,

zuerst einmal eine kleine Entschuldigung: Mir ist für mein "Problem" kein besserer Titel eingefallen. Ich änder ihn aber gerne ab, falls jemanden ein besserer Titel einfällt. Nun zum Problem:

Es geht mir um die Struktur und Aufgabenverwaltung von Objekten. Momentan ist es bei mir so, dass ein Objekt einen Datensatz aus der Datenbank repräsentiert. Jedes Objekt wird von einer Master-Klasse abgeleitet, welche die DB-Methoden "Select, Insert, Delete und Update" bereitstellt. Die Update und Delete-Methoden sind so programmiert, dass sie immer nur das Objekt in der DB ändern, welches diese Methode aufgerufen hat - also in der Master-Klasse wird fest eine ID des Datensatzes in die Where-Klausel eingesetzt. So können Objekte sich selbst ändern oder löschen.

Nun meine Frage: Angenommen wir bauen Autos und leiten von der Master-Klasse folgende Klassen ab um tolle Objekte zu erstellen: Auto, Reifen und Sitze. Das Auto soll auch wieder in der Datenbank gespeichert werden. Soll ich jetzt zum Speichern in der DB die Methoden des Objektes verwenden, oder soll ich für alle Klassen Verwalter-Klassen schreiben, die spezielle Verwaltungsmethoden übernehmen.

Beispiel 1 - Ohne Verwalterklasse

Delphi-Quellcode:

var
  Auto: TAuto;
  Reifen: TReifen;
  Sitz: TSitze;
begin
  Auto:=TAuto.Create;
  Reifen:=TReifen.Create;
  Sitz:=TSitze.Create;
  Reifen.Druck:=2;
  Sitz.Farbe:='Schwarz';
  Auto.Reifen:=Reifen;
  Auto.Sitz:=Sitz;
  Auto.Insert;
end;

Hier würde das erstellte Objekt zunächst keinen Datensatz der DB sein. Ich richte mein Objekt ein, konfiguriere es und lege es dann in der DB ab. Aber eine Verwalterklasse (zb. TAutos) bräuchte ich dennoch, um mehrere Autos zu verwalten oder abzuändern.

Beispiel 2 - Mit Verwalterklasse

Delphi-Quellcode:

var
  Autos: TAutos;
  Auto: TAuto;
  Sitze: TSitze;
begin
  Autos:=TAutos.Create;
  Autos.LadeAutosAusDerDB;
  ZeigeAlleAutosInEinerTreeViewAn();
  
  //Neues Auto bauen
  Auto:=TAuto.Create;
  Sitze:=TSitze.Create;
  Sitze.Farbe:='Schwarz';
  Auto.Farbe:='Quietschgelb';
  
  //Auto in der DB speichern; Verwalterklasse macht das!
  Autos.SpeicherInfosUeberNeuesAuto(Auto);

  //TreeView aktualisieren
  Autos.LadeAutosAusDerDB;
  ZeigeAlleAutosInEinerTreeViewAn();
end;

Ich hoffe, ihr erkennt den Unterschied und das, was ich mir dabei denke. Objekte in der DB ablegen soll nicht die Aufgabe eines "kleinen" Objektes sein - es soll nur einen Datensatz repräsentieren und alle DB-Aktionen ausführen können, die SICH SELBST betreffen.
Die Verwalterklasse soll sich um alles kümmern, was übergeordnet mit dem gesamten "Klassenthema" zusammenhängt, also "TAdressen", "TTiere" etc.

Ist das richtig, sinnvoll, zu kompliziert, hab ich mich komplett unverständlich ausgedrückt Ich kann das grad sehr schwer beschreiben, was ich mir da denke - aber ich hoffe, dass ihr es mit den Beispielen versteht.

Das Negative an der Sache ich, dass Verwalterklassen doch mehr Schreibarbeit bedeuten.

Nunja, ich lasse euch jetzt mit dem Roman mal kurz alleine.

Vielen Dank im Voraus!

[Alaitoc]

Hmm. ich würd das vll. so in etwa machen:

1. Erstellen eines Handlers
- verwaltet die Fahrzeuge in einer Liste
- kann Fahrzeuge hinzufügen
- kann Fahrzeuge entfernen
- kann Fahrzeuge in einer Treeview anzeigen
- kann Fahrzeuge in der Datenbank speichern / laden

2. Erstellen einer allgemeinen Fahrzeugklasse
- beinhaltet die Informations-Schnittstellen ( abstrakte Getter, Setter )

3. Erstellen der Fahrzeugtypen
- beinhaltet die spezifizierten Informationen

Vorteil wäre halt das man hier dann nur noch Änderungen an den Fahrzeugtypen machen müsste.
Ich würds aber je nach Anwendungsfall wahrscheinlich unterschiedlich machen, am einfachsten
ist es wenn man nen Lasten/Pflichtenheft erstellt und dann dazu UML-Diagramme erstellt.
Ist zwar lästig, aber kann sehr helfen

MfG Alaitoc

[TheMiller]

Ok, also der Handler wäre in diesem Fall meine Verwalterklasse TAutos.

Das mit den Autos ist ja nur ein Beispiel. Du würdest mir demnach zu Beispiel 2 raten. So mache ich das die ganze Zeit, wusste aber nicht, ob das so richtig ist. Es bedeutet ja dennoch mehr Aufwand. Aber bevor ich mein ganzes Projekt wieder umstelle, wollte ich halt bescheid wissen

Gibt's noch andere Ansichten?

[Blup]

Ich vermute du versuchst selbst ein eigenes Objektframework zu erstellen.
Das ist eine Aufgabe, die Jahre in Anspruch nehmen kann.
Schau dir erst an, was es bereits an (fast) fertigen Frameworks gibt (z.B. tiOPF).

Eine Datenklasse sollte nicht selbst das Lesen und Speichern in eine Datenbank implementiert.
Dadurch würde diese abhängig von einem bestimmten Datenbanksystem.
Jedes Datenobjekt braucht aber einen Status (zB. clean, neu, geändert, geloescht).

Vereinfachtes Beispiel wie so ein Framework funktionieren könnte:

Delphi-Quellcode:

Autos := TAutos.Create; // Autos hat den Zustand clean, da nichts zum Speichern enthalten

Auto := Autos.Add(TVolkswagen.Create); // Auto hat den Zustand neu, Autos ist geändert
Auto.Farbe := 'Quietschgelb';

Auto.Sitze := TSportSitze.Create; // Sitze hat den Zustand neu      
Auto.Sitze.Farbe := 'Schwarz';

DBInterface.Save(Autos);

Das DBInterface sucht auf Grundlage der Klasse des übergebenen Objekts und dessen Status den passenden vorher registrierten Writer und übergibt diesem Autos.
Für TAutos gibt es keinen eigenen Writer, es wird der Writer für die Elternklasse ausgewählt.
Der Writer (TDatenobjektliste, geändert) ist in diesem Fall einfach eine Schleife über alle Objekte, für jedes Objekt wird DBInterface.Save({...}) aufgerufen.
Da es speziell für TVolkswagen keinen eigenen Writer gibt, wird der Writer für die übergeordnete Klasse ausgewählt.
Der Writer (TAuto, neu) speichert zuerst untergeordnete Objekte DBInterface.Save(Auto.Sitze), dann das Autoobjekt an sich und zum Schluss die Beziehung Zwischen Auto und Sitze.
Der Writer (TSportSitze, neu) speichert lediglich das Sitzeobjekt.

Für das Speichern aller Autos würde dem DBInterface auch eine einfache TDatenobjektliste genügen.
Zum Laden wird aber eine TAutos Klasse benötigt, damit ein geeigneter Reader ausgewählt werden kann.
DBInterface.Read(Autos); Der Reader (TAutos, clean) löscht die Liste, holt für jedes Auto ID und Typ, erzeugt abhängig vom Typ die passende Autoklasse (TVolkswagen), setzt die ID und ruft DBInterface.Read(Auto) auf. usw.

[TheMiller]

Hallo,

vielen Dank für die Erklärung. Ist gerade etwas verwirrend, da ich es nur gelesen und noch nicht durchgearbeitet habe.

Wenn ich dich richtig verstehe, sagst du, dass meine Datenbankklasse (von der alle weiteren Objekte abgeleitet werden) mein Framework ist und es "nicht gut" ist, dass die Objekte TAuto und TSitze etc... von dem Datenbankobjekt abgeleitet sind?

Die Datenbankklasse selbst greift auf das Datenmodul "dmDatenbank" zurück, welches eine Zeos-Komponente enthält und auf Firebird-Embedded einrichtet ist.

Also meinst du, ich sollte meine Datenbankklasse und die Verwalterklassen so konzipieren, dass sie Datenbankunabhängig sind und die Objekte, mit denen ich letzlich arbeite sollten garnicht mit der Datenbank in berührung kommen. Richtig?

[Blup]

Datenobjekte sollten im Prinzip dumm sein.
Ihre einzige Aufgabe ist die Daten und deren Status aufzunehmen.
Sie stellen praktisch eine Schnittstelle zwischen Datenbankschicht, Anwendungskern und Visualisierung dar.
Deshalb zieht jede Änderung der Datenobjekte große Kreise.

Auf die Datenbankklasse sollte vom Anwendungskern nur über ein DB-unabhängige Interface zugegriffen werden.
Die Datenbankklasse selbst und Reader- und Writerklassen die bei der Datenbankklasse für die unterschiedlichsten Datenobjekte registriert werden, können und müssen natürlich teilweise Datenbankabhängig sein.

Der Anwendungskern bekommt aber von der Datenbankschicht nur ein einziges Interface, dem er Datenobjekte zum Lesen und Schreiben übergibt. Wenn man sich konsequent daran hält, kann man die Datenbank sogar zur Laufzeit wechseln.

[TheMiller]

Zitat:

Datenobjekte sollten im Prinzip dumm sein.

Schöner Satz, aber was bedeutet das genau für meine TAuto-Klasse...?

Wir haben ein Auto aus der Datenbank geladen und in einem Objekt der Klasse TAuto gespeichert. Darf/Sollte TAuto bzw. das konkrete Objekte Methoden haben, ausschließlich sich selbst zu ändern und zu löschen?

Alle Methoden, die mit mehreren Datensätzen zu tun haben (Alle anzeigen, bestimmte anzeige, alle löschen etc) sind bei mir in der Verwalterklasse (TAutos) und alle Methoden die für einen speziellen Datensatz gelten (FarbeÄndern etc...), sind in der Objektklasse (TAuto).

Hier mal meine derzeite Hierarchie

Code:

dmDatenbank (Datenbankmodul mit Zeos-Komponente)

TDBBaseFB = class(TObject) //Datenbank-Basis-FB = Firebird
"Objekte" = class(TDBBaseFB)

"Verwalterklassen" = class(TObjectlist)

Delphi-Quellcode:

TDBBaseFB = class(TObject)
private
  Fdb_path: String;              //Pfad zur DB
  Fdb_utf8: Boolean;             //UTF8?
  Ftabelle: String;              //Name der Tabelle
  FdbIDField: String;            //Feldname der ID
  FdbID: Integer;                //ID des Datensatzes
  FdbData: array of TSQLData;    //Parameter der Query
  FdbSQLWhere: String;           //Where-Condition
  FdbSelectFields: TStringList;  //Zum Selektieren spez. Felder
  procedure setDbPath(Value: String);
  procedure setDbUtf8(Value: Boolean);
  procedure set_db_params; virtual;
  procedure setTabelle(Value: String);
  procedure setDbIDField(Value: String);
  procedure setDbID(Value: Integer);
  procedure setDbWhereSQL(Value: String);
public
  {* Standard SQL-Aktionen / MUST HAVE *}
  procedure Select; virtual;
  procedure SelectFields(Fields: TStringList); virtual;
  procedure Insert; virtual;
  procedure Update; virtual;
  procedure Delete; virtual;
  ...

Durch die Vererbung dieser Methoden haben alle Objekte Zugriff auf die FB-Datenbank. Nun ist die Frage, wie ich dies nutze. Ich hatte für mich entschieden, Verwalterklassen zu benutzen, wenn mehrere Objekte tangiert werden, und direkten Zugriff zu erlauben, falls sich ein Objekt selbst ändern oder löschen will. Es kann sich aber nicht selbst in die Datenbank eintragen.

Es ist bei mir immernoch ein bissl durcheinander - sowohl im Kopf, als auch im Code...