Spring-DI / DelegatedConstructor / Factory für Dummies

[stahli]

Ich habe keine Erfahrung mit Interfaces, könnte mir aber inzwischen vorstellen, im nächsten Projekt mit solchen zu arbeiten.

Der Mehraufwand beim definieren der genutzen Klassen (durch zusätzliche Deklaration von Interfaces) und beim Erzeugen der Objekte (durch Zuweisung des Objektes an eine Interfacevariable) lässt sich durch eine bessere Strukturierung des Projektes rechtfertigen.

Wenn man dann die Objekte noch an einer zetralen Stelle erzeugen lässt und dann nur noch mit deren Schnittstellen arbeitet, hört sich das schon interessant an.

In dem Sinne habe ich verschiedenes nachgelesen, bekomme aber (mal wieder) nicht alles unter einen Hut.

Insbesondere konnte ich noch nicht klar verinnerlichen, wozu dieses Spring-Framework nun eigentlich gut ist.
Dann erschließt sich mir nicht der Sinn eines DelegatedConstructor (ich kann doch auch später einem Objekt ein anderes als Property zuweisen).
Und wie wird eine Factory i.d.R. eingesetzt?

Zwar habe ich von allem eine ungefähre Ahnung bekommen, aber der Geistesblitz blieb noch aus.

Wollt Ihr Euch mal hier zu dem Themenbereich austoben?

[schlecki]

Spring ist nützlich, um deine Objekte zu verwalten. Du kannst hier in der Konfiguration schon angeben, dass ein Interface nur als Singleton genutzt werden kann. Dann wird jede Anforderung an dieses Objekt immer die gleiche Instanz zurückliefern. Es gibt dann noch verschiedene andere Arten z.b. SingletonPerThread (o.ä.)...

Weiterhin musst du nur die Interfaces veröffentlichen, die implementierenden Klassen können komplett im implementation-Teil "versteckt" werden.

intf.pas:

Delphi-Quellcode:

interface

type
  IDatabase = interface(IInterface)
  // GUID
  end;

  IQuery = interface(IInterface)
  // GUID
  end;

implementation

end.

dbimpl.pas:

Delphi-Quellcode:

interface

implementation

uses
  Spring.Container,
  intf;

type
  TMyDatabase = class(TInterfacedObject, IDatabase)
  //
  end;

initialization
  GlobalContainer.RegisterComponent<TMyDatabase>.Implements<IDatabase>.AsSingletonPerThread;

qryImpl.pas:

Delphi-Quellcode:

interface

implementation

uses
  Spring.Container,
  intf;

type
  TMyQuery = class(TInterfacedObject, IQuery)
  //...
  public
    constructor Create(const database: IDatabase); retintroduce;
  end;

initialization
  GlobalContainer.RegisterComponent<TMyQuery>.Implements<IQuery>;

Dann sollte man einmalig: GlobalContainer.Build aufrufen. Dadurch werden alle "Regeln" scharf gestellt. Fortan kannst du mit

Delphi-Quellcode:

var 
  qry: IQuery;
begin
  qry := GlobalContainer.Resolve<IQuery>;
  // mit qry arbeiten
end;

ein IQuery-Object abrufen und damit arbeiten. Spring kümmert sich automatisch um Dependencies und erzeugt nötigenfalls die Database und reicht diese auch im Konstruktor an die Query weiter.

Gruß
schlecki

[neo4a]

Zitat von stahli:

Dann erschließt sich mir nicht der Sinn eines DelegatedConstructor (ich kann doch auch später einem Objekt ein anderes als Property zuweisen).

Ich beziehe mich einmal auf obiges Beispiel.

Spring ruft beim (internen) Instantiieren von TMyDatabase den Konstruktor ohne Parameter auf. Wenn das nicht geht, muss man bei GlobalContainer.RegisterComponent<TMyDatabase>.Implements<IDatabase>.AsSingletonPerThread noch Spring mitteilen, welcher Konstruktor verwendet werden soll. Hier kommt der DelegatedConstructor in's Spiel:

Delphi-Quellcode:

GlobalContainer.RegisterComponent<TMyDatabase>.Implements<IDatabase>.AsSingletonPerThread.DelegateTo(
    function: TMyDatabase
    begin
      Result := TMyDatabase.Create(nil);
    end
  )

Ansonsten ist das Spring-Framework mehr als nur ein DI-Container. Der ist aber der wichtigste Teil. Du weißt ja, dass DI (Dependency Injection) dazu führt, praktisch keine Objekte, die komplexer sind als etwa TStringList, mehr in der Klasse selbst zu erzeugen. Stattdessen bekommt die Klasse die notwendigen Instanzen der erforderlichen Klassen von "außen" zugewiesen.

Zitat:

Nicht das Auto prüft vor Abfahrt, ob die Räder montiert sind, sondern bei der Montage und vor der Abfahrt aus der Fabrik wird dem Auto alles notwendige an- und eingebaut.

Auch ohne die Notwendigkeit, sein Programm ohnehin zu flexibilisieren, gibt es immer genau einen Anwendungsfall für ein solches Vorgehen: der Test. Da schiebe ich (von außen) meiner Klasse alle die Szenarien unter (in Form von Mock-Instanzen), für die sie funktionieren soll.

So gesehen führt DI zu testbaren Code führt zu Clean-Code führt in den Programmierer-Himmel.

[Stevie]

Ich kann in diesem Bezug nur auf dieses Dokument von Miško Hevery verweisen. Dort wird anhand von simplen Beispielen (zwar in Java aber sollte kein Problem sein) erklärt, wie man bestimmte Dinge in seinem Code vermeidet (allem voran das Erstellen von neuen Objekten - simple Dinge wie z.B. Listen außen vor) und dadurch einfach zu wartenden und testbaren Code erstellt. Auch die in dem Dokument verlinkten Artikel sind sehr interessante Lektüre.

Auch lohnt es sich, diesen Vortrag von ihm zum gleichen Thema anzuschauen

[stahli]

Ok danke erst mal.

Mit dem Thema Testing tue ich mich etwas schwer. Ich habe mal zwei deutsche Seiten dazu gefunden:
http://sageniuz.wordpress.com/2010/0...ktoren-teil-1/
http://msdn.microsoft.com/de-de/magazine/dd263069.aspx
Ich denke, dass solche Tests nur sehr begrenzten Sinn machen. Jedenfalls sind die Probleme, die mir so unterkommen meist sehr komplexen Umständen geschuldet, die sich nicht mit ein paar Testobjekten reproduzieren lassen.
Mal reagiert die VCL etwas anders als erwartet (was z.B. irgendwelche Nachrichtenbehandlungen betrifft) oder in meinem Framework werden irgendwann Objekte nicht wie erwartet behandelt. Jedenfalls treten die Fehler meist nur durch eine intensive Userbedienung auf. In den Fällen dürfte ein Unittesting nicht helfen.
Das nur mal am Rande.

Interfaces zu nutzen und vielleicht auch Spring merke ich mir aber auf jeden Fall mal vor.
Muss mich aber erst noch ein bissl mehr damit beschäftigen.

In meiner Turniersoftware merke ich jetzt zumindest allmählich, dass pure Objekte noch nicht wirklich das Wahre sind. Diese irgendwo zentral zu erzeugen und dann mit Interfaces weiter zu arbeiten, stelle ich mir (inzwischen) sehr übersichtlich vor. Ich werde das Projekt jetzt erst mal zum Ende bringen und später mal eine Überarbeitung andenken.

[s.h.a.r.k]

Zitat von stahli:

Mal reagiert die VCL etwas anders als erwartet (was z.B. irgendwelche Nachrichtenbehandlungen betrifft) oder in meinem Framework werden irgendwann Objekte nicht wie erwartet behandelt. Jedenfalls treten die Fehler meist nur durch eine intensive Userbedienung auf. In den Fällen dürfte ein Unittesting nicht helfen.

Klingt irgendwie komisch... Egal, wie die Nachrichtenbehandlung abläuft, es müsste immer das selbe Ergebnis folgen, egal, wie intensiv die Userbedienung ist. Selbst, wenn du Threads mit einbaust, muss dein Konzept immer die gleichen Ergebnisse liefern, ebenso muss dein Framework immer gleich mit Objekten umgehen, eben auf abstrakte Art und Weise. Die Besonderheiten sollten imho von den Objekten selbst gehandhabt werden.

[stahli]

Es ging mir um Fehler, die bei der Weiterentwicklung meiner datensensitiven Komponenten und meines Frameworks aufgetreten sind. Entweder haben die VCL-Controls (von denen ich ableite) teilweise nicht wie erwartet funktioniert oder ich habe den Ablauf meines Frameworks an irgendeiner Stelle problematisch verändert.
Diese Probleme hätte wohl kein Unit-Testing entdeckt - denke ich. Und Probleme, die ich mit einem Unit-Testing finden könnte, habe ich eigentlich nicht und wenn, sind sie eigentlich schnell zu bereinigen.

[Stevie]

Zitat von stahli:

Es ging mir um Fehler, die bei der Weiterentwicklung meiner datensensitiven Komponenten und meines Frameworks aufgetreten sind. Entweder haben die VCL-Controls (von denen ich ableite) teilweise nicht wie erwartet funktioniert oder ich habe den Ablauf meines Frameworks an irgendeiner Stelle problematisch verändert.
Diese Probleme hätte wohl kein Unit-Testing entdeckt - denke ich. Und Probleme, die ich mit einem Unit-Testing finden könnte, habe ich eigentlich nicht und wenn, sind sie eigentlich schnell zu bereinigen.

Du arbeitest allein an deinem Sourcecode. Stell dir vor, es gibt ein Team von Entwicklern und es gibt bestimmte Spezifikationen für die unterschiedlichen Module und Klassen. Baut sich nun jeder Entwickler seine Button1 Projekte, um zu testen, ob die Klassen und Methoden das machen, was sie sollen? Ob nun TDD betrieben wird, oder erst drauflos gecodet wird und hinterher der Unittest geschrieben wird, ist dafür erstmal unerheblich. Was, wenn nun Funktionialität hinzukommt, sich Spezifikationen ändern, jemand Dinge refactored oder ein unbedarfter Azubi auf den Code losgelassen wird? Willst du deine komplette zig Millionen LoC schwere Anwendung durchtesten, um herauszufinden, ob alles noch funktioniert?

[stahli]

Ok, in Bezug auf die Teamarbeit ist das gewissermaßen schon nachvollziehbar. Damit habe ich aber (leider oder zum Glück?) keine Erfahrungen.
Die Testfälle zu organisieren ist aber sicher auch nicht trivial und kostet viel Zeit und Arbeit.

Da ich immer im eigenen Saft schmore und mit meinem eiegntlichen Projekt voran kommen will, habe ich leider wenig Zeit mich mit für mich neuen Grundlagen zu befassen. Im nächsten Leben werde ich mal bei Dir Azubi und lerne das gleich richtig.

[Uwe Raabe]

Zitat von stahli:

Da ich immer im eigenen Saft schmore und mit meinem eiegntlichen Projekt voran kommen will, habe ich leider wenig Zeit mit frü mich neuen Grundlagen zu befassen.

Dann geht es dir wie dem Bauern, der keine Zeit hat, einen Zaun zu bauen, weil er die Kühe einfangen muss...