AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Problem mit Klassendesign

Ein Thema von jus · begonnen am 31. Jan 2017 · letzter Beitrag vom 8. Feb 2017
Antwort Antwort
Seite 2 von 3     12 3   
Benutzerbild von p80286
p80286

Registriert seit: 28. Apr 2008
Ort: Stolberg (Rhl)
6.659 Beiträge
 
FreePascal / Lazarus
 
#11

AW: Problem mit Klassendesign

  Alt 3. Feb 2017, 08:56
@TBx
Danke! Ich hatte ein eigenes Interface für jede DB erwartet. Werde mir das mal bei Gelegenheit anschauen.

Gruß
K-H
Programme gehorchen nicht Deinen Absichten sondern Deinen Anweisungen
R.E.D retired error detector
  Mit Zitat antworten Zitat
Aviator

Registriert seit: 3. Jun 2010
1.611 Beiträge
 
Delphi 10.3 Rio
 
#12

AW: Problem mit Klassendesign

  Alt 3. Feb 2017, 09:36
@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.
  Mit Zitat antworten Zitat
Benutzerbild von DeddyH
DeddyH

Registriert seit: 17. Sep 2006
Ort: Barchfeld
27.617 Beiträge
 
Delphi 12 Athens
 
#13

AW: Problem mit Klassendesign

  Alt 3. Feb 2017, 12:15
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.
Detlef
"Ich habe Angst vor dem Tag, an dem die Technologie unsere menschlichen Interaktionen übertrumpft. Die Welt wird eine Generation von Idioten bekommen." (Albert Einstein)
Dieser Tag ist längst gekommen
  Mit Zitat antworten Zitat
Aviator

Registriert seit: 3. Jun 2010
1.611 Beiträge
 
Delphi 10.3 Rio
 
#14

AW: Problem mit Klassendesign

  Alt 3. Feb 2017, 13:33
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.
  Mit Zitat antworten Zitat
Benutzerbild von DeddyH
DeddyH

Registriert seit: 17. Sep 2006
Ort: Barchfeld
27.617 Beiträge
 
Delphi 12 Athens
 
#15

AW: Problem mit Klassendesign

  Alt 3. Feb 2017, 13:51
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.
Detlef
"Ich habe Angst vor dem Tag, an dem die Technologie unsere menschlichen Interaktionen übertrumpft. Die Welt wird eine Generation von Idioten bekommen." (Albert Einstein)
Dieser Tag ist längst gekommen
  Mit Zitat antworten Zitat
HolgerX

Registriert seit: 10. Apr 2006
Ort: Leverkusen
969 Beiträge
 
Delphi 6 Professional
 
#16

AW: Problem mit Klassendesign

  Alt 3. Feb 2017, 16:07
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..
  Mit Zitat antworten Zitat
freimatz

Registriert seit: 20. Mai 2010
1.440 Beiträge
 
Delphi 11 Alexandria
 
#17

AW: Problem mit Klassendesign

  Alt 3. Feb 2017, 16:44
Jetzt weiß ich endlich, was Ihr immer mit einer Factory meint
https://de.wikipedia.org/wiki/Abstrakte_Fabrik
https://de.wikipedia.org/wiki/Fabrikmethode
  Mit Zitat antworten Zitat
Benutzerbild von p80286
p80286

Registriert seit: 28. Apr 2008
Ort: Stolberg (Rhl)
6.659 Beiträge
 
FreePascal / Lazarus
 
#18

AW: Problem mit Klassendesign

  Alt 3. Feb 2017, 17:14
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
Programme gehorchen nicht Deinen Absichten sondern Deinen Anweisungen
R.E.D retired error detector
  Mit Zitat antworten Zitat
Benutzerbild von DeddyH
DeddyH

Registriert seit: 17. Sep 2006
Ort: Barchfeld
27.617 Beiträge
 
Delphi 12 Athens
 
#19

AW: Problem mit Klassendesign

  Alt 3. Feb 2017, 17:50
Genau, sonst könnte man sich das ganze Geraffel ja auch schenken.
Detlef
"Ich habe Angst vor dem Tag, an dem die Technologie unsere menschlichen Interaktionen übertrumpft. Die Welt wird eine Generation von Idioten bekommen." (Albert Einstein)
Dieser Tag ist längst gekommen
  Mit Zitat antworten Zitat
idefix2

Registriert seit: 17. Mär 2010
Ort: Wien
1.027 Beiträge
 
RAD-Studio 2009 Pro
 
#20

AW: Problem mit Klassendesign

  Alt 5. Feb 2017, 13:27
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.
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:47 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz