Spring-DI / DelegatedConstructor / Factory für Dummies

[Stevie]

Zitat:

Zitat von stahli (Beitrag 1150317)

Auf diese Weise kennt ein Spiel zwar nicht unmittelbar sein Turnier, kann dieses aber bei Bedarf ermitteln und dort z.B. die Ermittlung der Platzierungen veranlassen (das sollte ja erfolgen, wenn ein Spiel neue Ergebnisse hat).

Für SOOO schlecht halte ich dieses Konstrukt eigentlich nicht.

Ich schon. Was hat ein Spiel mit den Platzierungen zu tun? Ich werf nochmal so einen Begriff in den Raum: Single Responsibility Prinzip. Lösung für das Konkrete Problem: Observer (aka Events)

Zitat:

Zitat von stahli (Beitrag 1150317)

Deinen letzten Satz kann ich nicht im Detail nachvollziehen. Sollte man BL-Klassen und Datenklassen getrennt definieren und erzeugen? Wo liegt der Vorteil?

Klares kommt drauf an. Aber es geschieht oft, dass die Businesslogik in diesen Klassen fehl am Platz sind und man damit zwangsläufig wieder irgendwelche Prinzipien (z.B. LoD oder SRP) verletzt. In deinem geschilderten Fall könnte es aber in der Tat Sinn ergeben, den Weg über einen Container zu gehen.

Um es nochmal zu erwähnen: Beschäftigt euch erst mit DI an sich, verinnerlicht, was man dadurch gewinnt und was man ggf aufgeben muss (in der Regel schlechte Angewohnheiten). Die Benutzung eines DI Containers ist eine Stufe weiter. Wenn man nicht manuell DI betreiben kann (TSomeComponent.Create(OtherComponent) IST dependency injection!), kann man's auch nicht mit nem Container.

Zitat:

Zitat von exilant (Beitrag 1150315)

Ich bin in der gleichen Situation wie Stahli, arbeite also an allein an einem über die Jahre gewachsenem Projekt. Ich habe mich in letzter Zeit ebenfalls mit den hier besprochenen Teckniken beschäftigt und sie für mich verworfen. Das ganze Kram führt zu imo zu "over engeneering". Zu Spring habe ich eine Session bei der EKON besucht und diverse Literatur durchgeackert. Es ist mir gänzlich verborgen geblieben wobei mich ein solches Framework unterstützen könnte. Unit testing lohnt den Aufwand nicht, und Interfaces benutze ich nur wenn ich gezwungen bin mich mit COM zu beschäftigen. In meiner Software sehe ich keinerlei Mehrwert gegenüber abstrakten Methoden. Demeters Gesetz hat was für sich, als allgemeiner Ratschlag. Aber wer sich ständig dran hält schreibt sich die Finger Wund. Für (fast) nichts. Selbst Heiligtümer wie die GOF Patterns haben sich für mich als nur eingeschränkt nützlich erwiesen. Die eine oder andere Idee dahinter ist OK und lässt sich nutzen. Das war es aber auch schon. Wiederverwendbarkeit ist gut, aber um den alten Spruch zu bemühen: Was nach allen Seiten offen ist, ist vermutlich auch nicht ganz dicht. Offensichtlich schlage ich mich nur mit trivialen Problemen herum. Ich habe mich noch nicht in der Situation befunden, ein Problem nicht mit einer einfachen und klaren dem Anwendungsfall angepassten Objekthierachie lösen zu können. Es werden viele Säue durch viele Dörfer getrieben. Ich denke zu viele.

Ich arbeite selber an einem über Jahre gewachsenen Projekt und erlebe täglich die Probleme, die mit Nichtbeachtung diverser Prinzipien einherkommen (stundenlange Suche in weniger bekanntem Source und nachverfolgen bestimmter Programmabläufe durch Bereiche hindurch, wo sie nix zu suchen haben z.B.)

Was man davon hat, wenn bestimmte Schnittstellen nicht flexibel sind, kennt jeder, der schonmal von verschiedenen Herstellern ein Mobiltelefon hatte (hey, jeder hat seinen eigenen Stecker für das Ladekabel...) Und wie gut, dass man man in der Regel nicht beim Kauf einer neuen Glühbirne den Hersteller der Lampe wissen muss, weil die ihre eigenen Fassungen haben, oder? Oder dass der Hersteller seine Lampen nur mit 40 Watt Osram Birnen getestet hat und sie mit den anderen Herstellern kaputt geht. Aber bei Software muss immer alles ineiner verbacken sein und wenn man von Modularität spricht, wird die "over engeneering" Karte ausgespielt.

[exilant]

Zitat:

Zitat von Stevie (Beitrag 1150326)

[...] Aber bei Software muss immer alles ineiner verbacken sein und wenn man von Modularität spricht, wird die "over engeneering" Karte ausgespielt.

Niemand hat was gegen ordentliche Programmierung. Aber die Framework- und Patternbesessenheit führt zum "Schweizer Taschenmesser Syndrom". Die Teile sind flexibel bis zum abwinken und können immer mehr Dinge immer schlechter erledigen. Kein Mensch will mit sowas arbeiten. Ein Messer ist ein Messer und ein Schraubendreher ein Schraubendreher. Profis arbeiten nicht mit Schweizer Taschenmessern.

[neo4a]

Zitat:

Zitat von Stevie (Beitrag 1150273)

Zitat:

Zitat von neo4a (Beitrag 1150264)

Der (visuelle) Delphi-RAD-Ansatz, der den Einsatz mehrerer/vieler miteinander verknüpfter Komponenten bedeutet, steht einer vernünftigen, automatisierten Teststrategie entgegen.

Da muss ich dir ausnahmsweise mal widersprechen. ... Dennoch würde ich niemals meine GUI im Source zusammen bauen.

Ich habe mich nicht ganz präzise ausgedrückt, sorry. Was ich vor allem ansprechen wollte sind die GUI- und Persistenz- unterstützenden Komponenten, wo man halt dann die ganzen Properties im OI zusammenklickt.

Dass mein Beispiel nicht ganz passt, ist meinem Versuch geschuldet, den "Delphi-Weg" bei der Herangehensweise zu simulieren. Hätte ich vielleicht etwas besser machen können.

[neo4a]

Zitat:

Zitat von exilant (Beitrag 1150620)

Zitat:

Zitat von Stevie (Beitrag 1150326)

[...] Aber bei Software muss immer alles ineiner verbacken sein und wenn man von Modularität spricht, wird die "over engeneering" Karte ausgespielt.

Niemand hat was gegen ordentliche Programmierung. Aber die Framework- und Patternbesessenheit führt zum "Schweizer Taschenmesser Syndrom". Die Teile sind flexibel bis zum abwinken und können immer mehr Dinge immer schlechter erledigen. Kein Mensch will mit sowas arbeiten. Ein Messer ist ein Messer und ein Schraubendreher ein Schraubendreher. Profis arbeiten nicht mit Schweizer Taschenmessern.

Dein Beitrag ist aus meiner Sicht leider nur rhetorisch gut, denn: Modularität, Clean-Code und die Anwendung von Design Pattern hat doch nichts mit Besessenheit und "Flexibilität bis zum Abwinken" zu tun. Vielmehr bilden sie einen abgesicherten Regelsatz, der nicht nur, aber vor allem in der Teamarbeit soetwas wie eine STVO für Programmierer darstellt.

Und Deine Schlussfolgerung, dass nur der, wer auf diese Ansätze verzichtet, wahrhaft Ergebnisse für Profis abliefern kann, leuchtet mir nicht ein.

[exilant]

Zitat:

Zitat von neo4a (Beitrag 1150641)

Und Deine Schlussfolgerung, dass nur der, wer auf diese Ansätze verzichtet, wahrhaft Ergebnisse für Profis abliefern kann, leuchtet mir nicht ein.

Ich geb's zu. Der letzte Satz war eine rethorische Platzpatrone. Das mit der StVO verstehe ich durchaus. In einem Team wo die rechte nicht weiss was die linke tut sind verbindliche Spielregeln unerlässlich. Ich argumentierte auch ausdrücklich aus meiner Sicht: Einzelkämpfer. Ich wage die gar nicht so kühne Behauptung: Die Anzahl der Delphi Projekte in denen mit Dunit/DSpring gearbeitet wird ist verschwindend gering. Diese Erfahrung habe ich auf der letzten EKON machen dürfen als einer der Speaker in die Runde fragte, wer denn alles ein Unit Testing Framework einsetzt (ich glaube es war Herr Ua). Und er war sehr erstaunt (schockiert?) als sich kein Anwesender meldete. Mag daran liegen dass die Delphi Community durchaus an Überalterung leidet und man alten Hunden nur sehr schlecht neue Tricks beibringen kann. Aber nochmal (nicht Arrogant gemeint): Mein Problem bei der Softwareentwicklung ist nicht die Qualität sondern die Produktivität. Ich denke, das geht den meisten hier so.

"Patterns are unlikely to cover every aspect of an architecture. Any non-trivial design has lots of aspects that no pattern addresses. It’s up to you to fill in the spaces with your own creativity."

[neo4a]

Zitat:

Zitat von exilant (Beitrag 1150735)

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:

Zitat von Jens01 (Beitrag 1150772)

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:

Delphi-Quellcode:

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

Delphi-Quellcode:

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:

Zitat von Jens01 (Beitrag 1150806)

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).