Spring-DI / DelegatedConstructor / Factory für Dummies

[neo4a]

Zitat von exilant:

Mein Problem bei der Softwareentwicklung ist nicht die Qualität sondern die Produktivität.

Etwas weiter vorn gab's schon einmal ein Bild mit "Kuhzäunen". Und egal wie alt einer ist: Wer sich professionell mit IT-Themen beschäftigt, kennt die schnellen Zyklen und die kurzen Halbwertzeiten von IT-Expertenwissen. Ich bin überzeugt, dass es zwischen Qualität und Produktivität bei der Software-Entwicklung einen Zusammenhang gibt.

Einige Impulse kommen ja auch davon, dass viele Leute hier nicht mehr ausschließlich nur in Delphi unterwegs sind. Beispielsweise in XCode kommt man mit dem herkömmlichen Delphi-Ansatz nicht sehr weit.

Daraus mehme ich meine Motivation: Mache es schon in Delphi so, wie es auch in anderen Sprachen anwendbar ist, damit ein Sprach- oder Plattform-Wechsel im Idealfall nur noch eine Syntax-Umstellung ist.

Du kennst vielleicht schon die Erläuterungen auf Sourcemaking.com. Interessanterweise werden hier die Beispiele auch meist noch für Delphi ausgeführt.

[Jens01]

Ich verfolge ja gerade diesen Thread...

Wenn ich das richtig mit diesem Spring verstehe, dann muß man bei den Klassen konsequent Daten und Funktion aufteilen in je eine Extra-Klasse und die Klasse mit den Funktionen kommt dann in diesen GlobalContainer.

Verstehe ich das richtig?

Gruss Jens

[neo4a]

Zitat von Jens01:

Verstehe ich das richtig?

Hier ein kleines Kochbuch:

Das Prinzip des Spring-DI-Containers ist - mit etwas Phantasie - vergleichbar mit den Abläufen bei der Automontage. Dort ist es ja eher unüblich, beim Montieren (Create) des Autos die Bestandteile (Motor, Blinker etc.) ebenfalls mit herzustellen: sie werden stattdessen aus dem Warenlager (DI-Container) so beigestellt, wie sie in der Produktion beim Create() des Autos benötigt werden.

In Spring meldest Du die Klassen, die Du im Warenlager verwalten willst, im einfachsten Fall so an:

Delphi-Quellcode:

unit uMotor;

interface 

uses
  classes;

type
  IMotor = interface
    ['{F23C0AAF-0D7F-4CFF-A4A6-FDEB4EC5FDF0}']
    procedure Brumm;
  end;

implementation

uses
  Spring.Container,
  Spring.Services;

type 
  TMotor  = class(TInterfacedObject, IMotor)
  private
    procedure Brumm; 
  end;

initialization
  GlobalContainer.RegisterComponent<TMotor>.Implements<IMotor>.AsSingleton;

Das passiert analog auch in den Units uBlinker etc.

Ich rufe i.d.R. in der dpr-Datei auf:
GlobalContainer.Build; Dieser einmalige Aufruf ist erforderlich, damit der Container weiß, dass alles beieinander ist. Vergisst man das, so gibt's später eine Fehlermeldung.

Dort, wo der Motor benötigt wird, macht man nicht mehr FMotor := TMotor.Create(); , sondern:

Delphi-Quellcode:

var
  aMotor : IMotor;
begin
  aMotor := ServiceLocator.GetService<IMotor>;
  aMotor.Brumm;

Das ist erst einmal schon alles. Damit man nicht die Unit uMotor einbinden muss, sollte die Interface-Deklaration von IMotor in eine eigene Unit ausgelagert werden. Bei mir sieht das z.B. so aus:

Delphi-Quellcode:

unit uInterfaces;

interface

uses
  Classes, SysUtils,

  uMotor, uBlinker
  ;

  procedure DI_Build;

type  
  IMotor = uMotor.IMotor;
  function DI_Motor : IMotor;
type  
  IBlinker = uBlinker.IBlinker;
  function DI_Blinker : IBlinker;

implementation

uses
  Spring.Container,
  Spring.Services;

procedure DI_Build; begin GlobalContainer.Build; end;

function DI_Motor : IMotor;
begin 
  Result := ServiceLocator.GetService<IMotor>;
end;

function DI_Blinkr : IBlinker;
begin 
  Result := ServiceLocator.GetService<IBlinker>;
end;

Mit Einbindung von uInterface braucht man in der aufrufenden Unit keine speziellen Units von Spring oder Motor einzubinden. Damit sind die Klassen vollständig entkoppelt. Das einzige Bindglied ist der DI-Container und der löst alles über Interfaces auf.

Mein typischer Aufruf sieht dann bspw. so aus:

Delphi-Quellcode:

var
  aMotor : IMotor;
begin
  aMotor := DI_Motor;
  aMotor.Brumm;

Der Spring-Container erfüllt dabei mehrere Funktionen: Er erzeugt die angeforderte Klassen, verwaltet deren Instanzen und gibt sie damit auch wieder frei. Die mitgelieferten Spring-Beispiele zeigen die weiteren Möglichkeiten. Mein Beispiel sollte nur zeigen, wie einfach der Einstieg sein kann und dass die Spring-Funktionalität sich nicht zu sehr aufdrängt.

Wofür das alles nun? Dadurch, dass an der Stelle, wo IMotor eingesetzt wird, nichts über TMotor und deren Unit bekannt sein muss, kann mann natürlich alles mögliche bereitstellen, solange es IMotor implementiert und damit die Prozedur Brumm() ausführen kann. Ganz klar auch, dass das Brummen im Motor-Teil erfolgen muss. An der konsumierenden Stelle hat man nichts über das Motor-Management zu wissen.

Nun ist der Motorwechsel einfach(er) und auch der Test eines Autos mit einem anderen oder Hilfs-Motor sollte kein Problem darstellen.

HTH.

[Jens01]

Ja, das habe ich soweit verstanden.
Bei mir hat sich aber ein anderes Problem dabei aufgetan.
Um bei Deinem Beispiel zu bleiben:
Es gibt jetzt eine Liste mit verschiedenen Autos und die Autos haben jeweils unterschiedliche Motoren.
Bei mir ist es jetzt so, wenn ich die Motoren mit "AsSingleton" registiere, dann haben alle Autos denselben Motor.

[neo4a]

Zitat von Jens01:

Bei mir ist es jetzt so, wenn ich die Motoren mit "AsSingleton" registiere, dann haben alle Autos denselben Motor.

Dann lasse das .AsSingleton weg, dann bekommt jedes Auto seinen eigenen Motor (.AsTransient).

[Jens01]

Ja, okay, dann geht es aber innerhalb eines einzelnen Autos nicht mehr.

[neo4a]

Zitat von Jens01:

Ja, okay, dann geht es aber innerhalb eines einzelnen Autos nicht mehr.

Ich benötige mehr Infos, eventuell konkrete Implementierungs-Details.

Ansonsten, wenn Du so initialisierst:
GlobalContainer.RegisterComponent<TMotor>.Implements<IMotor>; dann ersetzt Du

Delphi-Quellcode:

var 
  aMotor : TMotor;
begin
  aMotor := TMotor.Create();

mit

Delphi-Quellcode:

var
  aMotor : IMotor;
begin
  aMotor := ServiceLocator.GetService<IMotor>;

In beiden Fällen verweist aMotor auf eine spezielle Instanz.

[exilant]

Zitat von neo4a:

Wofür das alles nun? Dadurch, dass an der Stelle, wo IMotor eingesetzt wird, nichts über TMotor und deren Unit bekannt sein muss, kann mann natürlich alles mögliche bereitstellen, solange es IMotor implementiert und damit die Prozedur Brumm() ausführen kann. Ganz klar auch, dass das Brummen im Motor-Teil erfolgen muss. An der konsumierenden Stelle hat man nichts über das Motor-Management zu wissen.
Nun ist der Motorwechsel einfach(er) und auch der Test eines Autos mit einem anderen oder Hilfs-Motor sollte kein Problem darstellen.
HTH.

Autobeispiele sollten nicht mehr gewählt werden . Aber ich bleibe mal im Bild: Die Hierarchie haben wir jetzt vom Motor bis zum Fuhrparkleiter. Der will vielleicht nicht wissen wie der Motor im Wagen xy Brumm! macht, aber schon ob er Diesel oder Super will. Das muss er nämlich für seine Einsatzplanung bestellen. Das muss ich dem TFuhrparkleiter dann wieder über DI hintenrum mitteilen, oder wie? Obendrein sollte er noch die Betriebsstunden kennen, oder den Abschmierintervall um seinen Verfügbarkeitsplan aufzustellen. Aber der konsumierende muss ja nichts wissen...
Das ist mein Punkt. Und wenn ich am Ende angelangt bin, ist die ganze schöne Entkoppelung im Eimer. Oder habe ich da jetzt fundamental was nicht verstanden?

[BUG]

Zitat von exilant:

Der will vielleicht nicht wissen wie der Motor im Wagen xy Brumm! macht, aber schon ob er Diesel oder Super will. Das muss er nämlich für seine Einsatzplanung bestellen.

Meine Lösung wäre:
Der Fuhrparkleiter fragt das Auto, was es für Sprit will, das fragt den Motor und der muss es schließlich wissen.

[exilant]

Zitat von BUG:

Meine Lösung wäre:
Der Fuhrparkleiter fragt das Auto, was es für Sprit will, das fragt den Motor und der muss es schließlich wissen.

Klar. Das geht. Nur warum ist

if fuhrpark.eingeteiltesfahrzeug.motor.kraftoffart = diesel then einkaufsabteilung.dieselbestellen;

schlechter Stil? Genau das behauptet Demeter. Entkopplung ist Mythos.
Als Ausnahme lasse ich in der Tat nur die Entkopplung von GUI/BL gelten. Und auch da nur bedingt.