ClassFactory ähnlich wie Spring Framework, Hilfe gesucht!

[Mavarik]

Zitat:

Zitat von Stevie (Beitrag 1246960)

Leider geht das so nicht. Deshalb gibt es in Spring4d auch relativ komplexe Logik, um den "best matching" Konstruktor zu finden.

Dein Einwand bezieht sich aber "nur" auf Konstruktoren die Parameter haben, oder?

Der Einfache TFoo.Create; macht doch keine Probleme...

Mavarik

[Stevie]

Zitat:

Zitat von Mavarik (Beitrag 1246961)

Zitat:

Zitat von Stevie (Beitrag 1246960)

Leider geht das so nicht. Deshalb gibt es in Spring4d auch relativ komplexe Logik, um den "best matching" Konstruktor zu finden.

Dein Einwand bezieht sich aber "nur" auf Konstruktoren die Parameter haben, oder?

Der Einfache TFoo.Create; macht doch keine Probleme...

Mavarik

Ja, aber da du im Eingangspost erwähnt hast, dass es für TForm ginge, hab ich das geschrieben. Denn obwohl der Source kompiliert und auch TForm.Create aufgerufen wird (was ja nicht gehen dürfte, denn der ist durch den TComponent Konstruktor nunmal verdeckt), wird das Form ziemlich vor die Wand semmeln, da alles, was so in den Konstruktoren ab TComponent gemacht wird, nicht ausgeführt wird.

[Mavarik]

Zitat:

Zitat von Stevie (Beitrag 1246966)

Ja, aber da du im Eingangspost erwähnt hast, dass es für TForm ginge,

Nein! Geht mir um normale Klassen für TForms habe ich schon ein Formfactory programmiert.

Mavarik

[Stevie]

Noch'n Tip: Lagere das Register in eine extra Unit aus und mach das nicht im initialization Part der Unit mit der Klasse.
Dadurch erreichst du nämlich keineswegs eine Entkopplung sondern nur 1. Untestbarkeit deiner Klasse (dadurch, dass sie im Implementation Teil deiner Unit versteckt ist) und 2. indirekte Kopplung deiner Klasse auf den Container (dadurch, dass die Container Unit im Uses deiner Klassen Unit steht).

[Mavarik]

Zitat:

Zitat von Stevie (Beitrag 1246971)

Noch'n Tip: Lagere das Register in eine extra Unit aus und mach das nicht im initialization Part der Unit mit der Klasse.
Dadurch erreichst du nämlich keineswegs eine Entkopplung sondern nur 1. Untestbarkeit deiner Klasse (dadurch, dass sie im Implementation Teil deiner Unit versteckt ist) und 2. indirekte Kopplung deiner Klasse auf den Container (dadurch, dass die Container Unit im Uses deiner Klassen Unit steht).

Sehe ich anders. Im InitPart ist es schön! Da ja auch die Klasse in der Unit definiert ist. Die Referenz zum Container stört mich nicht. Wie soll ich den das in einer anderen Unit machen? Aus einer anderen Unit komme ich doch nicht an die Klasse ran!

Mavarik

[Union]

Stevie hat aber Recht mit der Entkopplung. Das hatten wir gestern schon mal. Genau wie Supports ;)

[TiGü]

Zitat:

Zitat von Mavarik (Beitrag 1246997)

Wie soll ich den das in einer anderen Unit machen? Aus einer anderen Unit komme ich doch nicht an die Klasse ran!

Ganz einfach!

Delphi-Quellcode:

unit MyInterfaces;

interface

const
  SID_Sample      : string = '{13B2116B-B78B-4E89-8070-83F9E36720EF}';
  SID_OtherSample : string = '{74EF1A68-1EED-4DA4-9845-5F77AEB6D2DA}';

type
  ISample = interface(IUnknown)
  [SID_Sample]
    procedure Foo;
    function Bar : Boolean;
  end;

  IOtherSample = interface(IUnknown)
  [SID_OtherSample]
    procedure FooFoo;
    function BarHocker : Boolean;
  end;

implementation

end.

Den Spaß werden wir hier implementieren:

Delphi-Quellcode:

unit MyClasses;

interface

uses
  MyInterfaces;

type
  TMySampleClass = class(TInterfacedObject, ISample)
  private
    function Bar: Boolean;
    procedure Foo;
  end;

  TMyOtherSampleClass = class(TMySampleClass, IOtherSample)
  private
    function BarHocker: Boolean;
    procedure FooFoo;
  end;

implementation

{blablabla - Methoden über Methoden}

end.

Die Unit Container ist ja jedem hier bekannt; so melden wir alle schön an:

Delphi-Quellcode:

unit RegisterMyClasses;

interface

implementation

uses
  Container, MyInterfaces, MyClasses;

initialization
  Container.GlobalContainer.RegisterClass<ISample, TMySampleClass>;
  Container.GlobalContainer.RegisterClass<IOtherSample, TMyOtherSampleClass>;

end.

Tataaaa! :party:

[Mavarik]

Wie war noch das Design-Pattern!

Niemals Klassendefinitionen im Interface Teil. Sonst Referenziert man noch dagegen?

Mavarik

[Stevie]

@Mavarik
Den Zahn hab ich Nick Hodges schon lange gezogen, der das ne Weile gepredigt hat - aus genau den oben genannten Gründen.
Das Verstecken von Klassen im Implementation Teil, damit sie ja keiner so nutzt, ist Unfug, wenn man sie dann über ein Interface von hintenrum verfügbar macht. Denn das ist der Tod für jegliche Testbarkeit der Klasse und dann fangen einige an, mit Compiler switches und weiß der Teufel das ganze für Unittests sichtbar zu machen. Außerdem ist das garantiert kein Design Pattern sondern eine Delphi Eigenheit.

Außerdem sollte man seinen Code so schreiben, dass er auch ohne einen DI Container durch manuelles Zusammenstecken funktionieren würde. Und das ist hier auch nicht der Fall.

@TiGü
:thumb:

[Der schöne Günther]

Ich habe den Thread noch nicht gelesen und mir für's Wochenende aufgehoben.

Weniger zu Spring (für deine unermüdliche Arbeit an Spring4D stelle ich in meinem Garten irgendwann mal eine Statur mit Lorbeerkranz von dir auf), sondern zu Klassen-Sichtbarkeit:

Klassendefinitionen als Ersatz für "protected/package/... class" in den implementation-Teil zu schieben handhabe ich teilweise auch noch so. Habt Ihr die Diskussion öffentlich geführt? Rein interessenshalber.