Problem mit Klassendesign

[p80286]

@TBx
Danke! Ich hatte ein eigenes Interface für jede DB erwartet. Werde mir das mal bei Gelegenheit anschauen.

Gruß
K-H

[Aviator]

Zitat von p80286:

@TBx
Danke! Ich hatte ein eigenes Interface für jede DB erwartet. Werde mir das mal bei Gelegenheit anschauen.

Gruß
K-H

Das würde ja gerade den Sinn von Interfaces zerstören. Hier geht es ja gerade darum, dass du immer mit dem gleichen Interface und den gleichen Methoden arbeitest. Lediglich bei der Erstellung der Interface Instanz wird dann entweder TMySql oder TMySqlPhpTunnel erstellt. Das wiederum kann dann später eine Factory erledigen. Wobei ich das auch noch nicht gemacht habe und da bei mir auch noch ein paar Verständnisprobleme vorliegen.

[DeddyH]

Ich habe jetz mal eine kleine Demo für so eine Factory gebaut, vielleicht lichtet das die Verständnisprobleme ein wenig. Stevie kann das zwar mit Sicherheit besser als ich, aber meins funktioniert bislang auch ganz manierlich. Zunächst also das Interface, um das es gehen soll:

Delphi-Quellcode:

unit TierIntf;

interface

type
  ITier = interface
    ['{9DC595F6-9026-4C4B-9FAC-5CCC5437C8A5}']
    procedure GibLaut;
  end;

implementation

end.

Das ist auch das einzige, was alle beteiligten Parteien später kennen werden. Jetzt kommt auch schon der schwierigste Teil, die Factory. Es handelt sich dabei um einen Singleton mit 2 öffentlichen Methoden: Registrierung einer das o.a. Interface implementierenden Klasse für ein String-Kriterium und Rückgabe einer Instanz einer der registrierten Klassen anhand eines String-Kriteriums. Letzteres ist eine recht haarige Angelegenheit, da man möglichst den passenden Konstruktor der jeweiligen Klasse ermitteln muss. Ein einfaches Create ruft nämlich den Konstruktor von TObject auf, der nützt uns herzlich wenig. Ich gehe daher per RTTI die Methoden der Klasse durch und suche nach dem ersten Konstruktor. Besitzt dieser Parameter, werden diese einfach mit Null-Entsprechungen befüllt, anschließend wird der Konstruktor dann aufgerufen.

Delphi-Quellcode:

unit TierFactory;

interface

uses System.Generics.Collections, System.SysUtils, System.Rtti, TierIntf;

type
  EMismatchingClass = class(Exception);

  TTierFactory = class abstract
  private
    class var FCollection: TDictionary<string, TClass>;
    class constructor Create;
    class destructor Destroy;
  public
    class procedure RegisterClassFor(Description: string;
      AClass: TClass); static;
    class function GetRegisteredInstanceFor(Description: string): ITier; static;
  end;

implementation

{ TTierFactory }

class constructor TTierFactory.Create;
begin
  FCollection := TDictionary<string, TClass>.Create;
end;

class destructor TTierFactory.Destroy;
begin
  FCollection.Free;
end;

class function TTierFactory.GetRegisteredInstanceFor
  (Description: string): ITier;
var
  TheClass: TClass;
  TheInstance: TObject;
  Tier: ITier;
  ctx: TRttiContext;
  AType: TRttiType;
  Value: TValue;
  TheMethod: TRttiMethod;
  ParamList: TList<TValue>;
  TheParam: TRttiParameter;
begin
  Result := nil;
  if FCollection.TryGetValue(AnsiLowerCase(Description), TheClass) then
    begin
      ctx := TRttiContext.Create;
      try
        AType := ctx.GetType(TheClass);
        for TheMethod in AType.GetMethods do
          if TheMethod.IsConstructor then
            begin
              ParamList := TList<TValue>.Create;
              try
                for TheParam in TheMethod.GetParameters do
                  begin
                    TValue.Make(0, TheParam.ParamType.Handle, Value);
                    ParamList.Add(Value);
                  end;
                TheInstance := TheMethod.Invoke(TheClass,
                  ParamList.ToArray).AsObject;
                Supports(TheInstance, ITier, Tier);
                Result := Tier;
              finally
                ParamList.Free;
              end;
              break;
            end;
      finally
        ctx.Free;
      end;
    end;
end;

class procedure TTierFactory.RegisterClassFor(Description: string;
  AClass: TClass);
begin
  if not Supports(AClass, ITier) then
    raise EMismatchingClass.CreateFmt
      ('Klasse %s implementiert das ITier-Interface nicht', [AClass.ClassName]);
  FCollection.AddOrSetValue(AnsiLowerCase(Description), AClass);
end;

end.

Jetzt noch eine Beispielklasse. Diese muss (natürlich) das Interface kennen, das sie implementieren soll, sowie die Factory, an der sie sich registriert. Die Registrierung selbst nehme ich im Initialization-Abschnitt vor, dann genügt das Einbinden der Unit, um die Klasse bekannt zu machen.

Delphi-Quellcode:

unit Hund;

interface

uses TierIntf, TierFactory;

type
  THund = class(TInterfacedObject, ITier)
  public
    procedure GibLaut;
  end;

implementation

uses Dialogs;

{ THund }

procedure THund.GibLaut;
begin
  ShowMessage('Ich bin ein ' + ClassName);
end;

initialization
  TTierFactory.RegisterClassFor('Hund', THund);

end.

Für weitere Tierarten kann man diese Unit einfach kopieren und alle Vorkommen von "Hund" einfach durch "Katze", "Vogel", "Fisch" oder sonstwas ersetzen.
Zum Schluss noch das Hauptprogramm. Die MainUnit muss das Interface und die Factory kennen, aber nicht die zu instanzierenden Klassen. Ich habe einfach ein Edit und einen Button auf das Formular geklatscht.

Delphi-Quellcode:

unit TestMain;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls;

type
  TfrmFactoryTest = class(TForm)
    edtTierart: TEdit;
    btnInstanz: TButton;
    procedure btnInstanzClick(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  frmFactoryTest: TfrmFactoryTest;

implementation

{$R *.dfm}

uses TierFactory, TierIntf;

procedure TfrmFactoryTest.btnInstanzClick(Sender: TObject);
var
  Tier: ITier;
begin
  Tier := TTierFactory.GetRegisteredInstanceFor(edtTierart.Text);
  if Assigned(Tier) then
    Tier.GibLaut
  else
    ShowMessage(Format('Keine registrierte Klasse für "%s" gefunden', [edtTierart.Text]));
end;

end.

Das war alles, wer grobe Fehler finden sollte, bitte korrigieren.

[Aviator]

Im Prinzip ist das alles so wie ich es schon kannte und auch verstanden habe. Allerdings bleibt es dann nicht aus, im Hauptprogramm immer einen entsprechenden String zu ändern wenn man im Falle von jus immer eine andere Datenbank nutzen möchte.

Dann könnte ich ja im Prinzip direkt die Instanz erzeugen und wäre genau so weit. Einziger Nachteil wäre dann, dass sich der Klassenname nie ändern dürfte, da dieser dann nicht mehr im Hauptprogramm gefunden würde.

[DeddyH]

Dieser String kann aber auch genausogut aus einer Konfigurationsdatei kommen (IniFile, XML, Registry, whatever). Im Hauptprogramm ändert sich dadurch nicht eine Zeile, aber die zu verwendende Datenbank kann so flexibel fesgelegt werden.

[HolgerX]

Hmm..

@DeddyH

Danke für deine Demo..

Jetzt weiß ich endlich, was Ihr immer mit einer Factory meint

Das ich das (nur ohne Interfaces) für Formulare in meinen Programmen bereits eingesetzt habe und so nur mit einer Art ID über einen CallForm(..) ein Formular erzeugen/Anzeigen konnte, incl. Übergabe von Parametern und Rückgabe von Werten..

[freimatz]

Zitat von HolgerX:

Jetzt weiß ich endlich, was Ihr immer mit einer Factory meint

https://de.wikipedia.org/wiki/Abstrakte_Fabrik
https://de.wikipedia.org/wiki/Fabrikmethode

[p80286]

Zitat von DeddyH:

Dieser String kann aber auch genausogut aus einer Konfigurationsdatei kommen (IniFile, XML, Registry, whatever). Im Hauptprogramm ändert sich dadurch nicht eine Zeile, aber die zu verwendende Datenbank kann so flexibel fesgelegt werden.

Das ist ja wohl das grundsätzliche Bestreben, selbst wenn man z.Zt. mit z.B. mehreren Datenmodulen hantiert.

Gruß
K-H

[DeddyH]

Genau, sonst könnte man sich das ganze Geraffel ja auch schenken.

[idefix2]

Zitat von DeddyH:

Letzteres ist eine recht haarige Angelegenheit, da man möglichst den passenden Konstruktor der jeweiligen Klasse ermitteln muss. Ein einfaches Create ruft nämlich den Konstruktor von TObject auf, der nützt uns herzlich wenig. Ich gehe daher per RTTI die Methoden der Klasse durch und suche nach dem ersten Konstruktor. Besitzt dieser Parameter, werden diese einfach mit Null-Entsprechungen befüllt, anschließend wird der Konstruktor dann aufgerufen.

An der Stelle hakt meines Erachtens die Praxistauglichkeit des Konzepts. Wenn ein Create Parameter annimmt, dann im allgemeinen nicht aus Jux und Tollerei, sondern weil die Parameterwerte für irgend etwas gebraucht werden. In der Factory einfach Nullwerte für die Parameter anzunehmen, wird in aller Regel keine sinnvollen Ergebnisse bringen, oder irre ich mich da? Und wenn das Hauptprogramm keinerlei Kenntnis von der zu erstellenden Klasse hat, wird es schwer adäquate Parameter bereitstellen können.