AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Algorithmen, Datenstrukturen und Klassendesign Delphi Spring-DI / DelegatedConstructor / Factory für Dummies

Spring-DI / DelegatedConstructor / Factory für Dummies

Ein Thema von stahli · begonnen am 2. Feb 2012 · letzter Beitrag vom 15. Mär 2012
Antwort Antwort
Seite 1 von 10  1 23     Letzte » 
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.336 Beiträge
 
Delphi 11 Alexandria
 
#1

Spring-DI / DelegatedConstructor / Factory für Dummies

  Alt 2. Feb 2012, 12:45
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?
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
schlecki

Registriert seit: 11. Apr 2005
Ort: Darmstadt
148 Beiträge
 
Delphi XE2 Enterprise
 
#2

AW: Spring-DI / DelegatedConstructor / Factory für Dummies

  Alt 2. Feb 2012, 13:37
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
  Mit Zitat antworten Zitat
neo4a

Registriert seit: 22. Jan 2007
Ort: Ingolstadt
362 Beiträge
 
Delphi XE2 Architect
 
#3

AW: Spring-DI / DelegatedConstructor / Factory für Dummies

  Alt 2. Feb 2012, 14:42
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.
Andreas
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.007 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#4

AW: Spring-DI / DelegatedConstructor / Factory für Dummies

  Alt 2. Feb 2012, 15:14
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
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.336 Beiträge
 
Delphi 11 Alexandria
 
#5

AW: Spring-DI / DelegatedConstructor / Factory für Dummies

  Alt 8. Feb 2012, 21:22
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.
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
Benutzerbild von s.h.a.r.k
s.h.a.r.k

Registriert seit: 26. Mai 2004
3.159 Beiträge
 
#6

AW: Spring-DI / DelegatedConstructor / Factory für Dummies

  Alt 9. Feb 2012, 08:32
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.
»Remember, the future maintainer is the person you should be writing code for, not the compiler.« (Nick Hodges)
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.336 Beiträge
 
Delphi 11 Alexandria
 
#7

AW: Spring-DI / DelegatedConstructor / Factory für Dummies

  Alt 9. Feb 2012, 10:09
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.
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.007 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#8

AW: Spring-DI / DelegatedConstructor / Factory für Dummies

  Alt 9. Feb 2012, 10:52
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?
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.336 Beiträge
 
Delphi 11 Alexandria
 
#9

AW: Spring-DI / DelegatedConstructor / Factory für Dummies

  Alt 9. Feb 2012, 11:34
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.
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)

Geändert von stahli ( 9. Feb 2012 um 11:44 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe
Online

Registriert seit: 20. Jan 2006
Ort: Lübbecke
10.934 Beiträge
 
Delphi 12 Athens
 
#10

AW: Spring-DI / DelegatedConstructor / Factory für Dummies

  Alt 9. Feb 2012, 11:42
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...
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 10  1 23     Letzte » 

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 23:14 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