[OOP] Objekt anderen Objekten bekannt machen

[TheMiller]

Hallo Leute,

hab mal wieder ein Problem... - könnte aber auch an der Uhrzeit liegen.

Ich habe eine Datenbankklasse erstellt, welche die ZConnection und ZQuery beinhaltet (ZEOS). Nun leite ich im Programm ein Objekt davon ab und alles funktioniert einwandtfrei. Jetzt möchte ich Objekte erstellen, die die DB-Verbindung nutzen sollen. Ableiten von der Datenbankklasse kann/will ich nicht, da sonst mehrere bzw. viele Verbindungen zur Datenbank erstellt werden (ich mag nur eine pro Programm haben).

Nun mag ich aber, dass die Objekte das Datenbankobjekt trotzdem kennen, ohne, dass ich es ihnen jedes mal übergeben muss. Hier mal meine Klassen

Delphi-Quellcode:

//Globales Firebird-Datenbankobjekt, abgeleitet von DB_Base_Firebird <- DB_BASE
TJKDB = class(TDBBase_FB)
private
  //nothing
protected

public
  constructor Create; override; //Hier wird die einzige DB-Verbindung erstellt.
  destructor Destroy; override;
  procedure Save(Data: TObject);
end;

//Globales Datenobjekt, zum erneuten Ableiten und Erweitern
TJKObject = class(TObject)
private
  fDBO: TJKDB; //Hier könnte das DB-Objekt übergeben werden, ist aber auf Dauer zu "unbequem"
public
  constructor Create;
end;

Alle Objekte sind in einer gemeinsamen extra-Unit. Soll ich in dieser eine globale Variable deklarieren? Ist kein schöner Stil, zumal ich von dem Hauptprogramm auch auf das DB-Objekt zugreifen möchte...
Sollte ich es vielleicht so machen, dass ich alle Objekte - soweit erforderlich - vom DB-Objekt ableite und die Verbindung immer dann öffne und schließe, wenn es wirklich nötig ist?
Ich hatte auch schon eine Lösung mit einem Datenmodul. Da griffen alle Objekte, die eine DB-Verbindung wollten, auf das Datenmodul zu. Nachteil ist hier halt, dass ich nur eine DB-Verbindung haben kann und nicht mehrere - es sind ja keine Objekte.

Ich bitte verzweifelt um einen Rat ;)

Danke im Voraus

[Namenloser]

Du kannst ein Singleton nehmen. Dazu sollten sich Beispiele im Netz finden lassen.

[TheMiller]

Moin.

Ich weis nicht, ob das die elegante Lösung ist... Meine Klassen sehen mir eher nach einem Designfehler aus. Klar könnte ich die Datenbankverbindung in ein Datenmodul packen, aber dann hätte ich wieder keine objektorientierte Datenbankverbindung und kann demnach nur eine nutzen (ohne große Umwege).

[Namenloser]

Ich habe ja auch nicht von einem Datenmodul gesprochen, sondern von einem Singleton. Eine Singleton-Implementierung in Delphi findest du beispielsweise hier.

[TheMiller]

Hey,

das mit der Klasse habe ich schon verstanden. Aber ich finde, dass die Benutzung einer solchen Klasse nur nötig ist, wenn man einen Designfehler hat, quasi ein Workaround. Oder?

Würde ich eine solche Klasse benutzen, würde ich in jedem Constructor das Datenbankobjekt erstellen, aber immer nur die Referenz zurückbekommen, wenn das DB-Objekt schon erstellt wurde. Das ist doch so richtig, ja?

Mir stellt sich gerade die Frage: Designfehler oder nicht?

[Namenloser]

Naja, das ist häufig Ansichtssache - oft Singletons weisen schon auf Designfehler hin, allerdings gibt es - in Maßen einegsetzt - auch ein paar vernünftige Anwendungsbereiche; und das sind z.B. Datenbankverbindungen, die nur einmalig aufgebaut werden sollen. Solche werden jedenfalls meines Wissens nach oft mit einem Singleton umgesetzt.

Zumindest ist das Singleton eine Verbesserung gegenüber globalen Variablen.

[TheMiller]

Zitat:

Zumindest ist das Singleton eine Verbesserung gegenüber globalen Variablen.

Ich habe den ganzen DB-Kram ja in einer extra-Unit. Ist es so schlimm, wenn ich für die betreffenden Units (zwei Stück) eine globale Variable deklariere und somit von allen Objekten aus die DB nutzen kann? Mehrere Instanzen sind ja sogar ok - das wollte ich da.

Die eignetlichen Hauptprojekte bleiben davon unberührt. Dort brauche ich ja keine globale Variable, da mein Datenbankobjekt einen Zugriff auf das Datenmodul bereitstellt. Dann leite ich eben die DB-Anfragen etc. durch das Datenbankobjekt und kann vom Hauptprogramm nicht direkt auf das Datenmodul zugreifen.

Ist sogar recht ordentlich, oder?

[Medium]

So ganz so astrein ist das Beispiel aber auch nicht, hm? :)

Delphi-Quellcode:

class function TSingleton.NewInstance: TObject;
begin
  if ( not Assigned( Instance ) ) then
  begin
    Instance := inherited NewInstance;
    // Initialize private variables here, like this:
    //   TSingleton(Result).Variable := Value; <--------------------------
  end;
  Result := Instance
  Inc( Ref_Count );
end;

Wird interessant result zu casten und etwas zuzuweisen, wenn erst darunter Result:=Instance; gesetzt wird.
Edit: Schon klar, dass da TSingelton(Instance) stehen sollte, tut et abba nich.

[Namenloser]

War der 1. Treffer bei Google, und weil es auf der Embarcadero-Webseite war, bin ich davon ausgegangen, dass es wohl schon stimmen wird... :oops:

[edit]

Zitat:

Zitat von DJ-SPM

Ich habe den ganzen DB-Kram ja in einer extra-Unit. Ist es so schlimm, wenn ich für die betreffenden Units (zwei Stück) eine globale Variable deklariere und somit von allen Objekten aus die DB nutzen kann? Mehrere Instanzen sind ja sogar ok - das wollte ich da.

Was ich nicht ganz verstehe, ist deine Aussage, dass mehrere Instanzen ok wären - ich dachte, dass genau das (sinnvollerweise) vermieden werden sollte. Ein Problem ist, dass du immer von "DB-Objekten" sprichst, ohne genauer zu erläutern, was du damit meinst. Außerdem vermischt du Objekte mit Klassen.

Ich habe irgendwie das Gefühl, dass wir aneinander vorbeireden.

Vielleicht suchst du ja auch einfach klassenstatische Variablen?

Delphi-Quellcode:

  
  TJKDB = class(TDBBase_FB)
  public
    constructor Create;
    destructor Destroy; override;
    procedure Save(Data: TObject);
  end;

  TJKObject = class(TObject)
  strict private
    class var FDBO: TJKDB;
  strict protected
    class property DBO: TJKDB read FDBO;
  public
    constructor Create;
  end;

implementation

constructor TJKObject.Create;
begin
  if not Assigned(FDBO) then
    FDBO := TJKDB.Create;
end;

Auf die Eigenschaft DBO kannst du dann in allen abgeleiteten Klassen zugreifen, das dahinterliegende Objekt wird aber nur einmalig instanziiert.
[/edit]

[xZise]

Alternativ könntest du ein Event einführen, welches die obige Klasse triggert und dadurch ausführt?

MfG
Fabian