Spring-DI / DelegatedConstructor / Factory für Dummies

[stahli]

Die "Objekte" sind von TComponent abgeleitet (damit sie einen Owner haben und ich sie ggf. auch in der IDE einrichten kann) und enthalten Daten und BL.

Will ich in einem Spiel ermitteln, ob es sich in einem Turnier befindet, nutze ich eine lokale Variable und eine externe (in einer gesonderten Unit abgelegten) Funktion.

Delphi-Quellcode:

function OwnerTournament(C: TComponent): TodTournament;
begin
  Result := nil;
  if C is TodTournament then
    Result := (C as TodTournament)
  else if C.Owner <> nil then
    Result := OwnerTournament(C.Owner);
end;

Im Spiel dann etwa:

Delphi-Quellcode:

procedure TodGame.Calc;
var 
  MyTournament: TodTournament;
begin
  ...
  MyTournament := OwnerTournament(Self);
  if Assigned(MyTournament) then
    MyTournament.Calc;
  ...
end;

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.

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

Im Moment kann der User ein neues Projekt anlegen, was einem TodTournamentEvent.Create() entspricht. Einige SubObjekte werden dann automatisch (leer) hinzugefügt, z.B. Sportart und Ort. Diese SubObjekte können dann durch den User über bestimmte Formulare bearbeitet und gefüllt werden. Andere Objekte erzeugt der User bei Bedarf komplett neu (z.B. Vereine und deren Mitglieder).
Jedes Objekt beinhaltet seine eigene BL und kann sich bei Bedarf in seinem Umfeld zurecht finden. Starre Verdrahtungen gibt es aber kaum.

[Stevie]

Zitat von stahli:

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 von stahli:

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 von exilant:

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 von Stevie:

[...] 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 von exilant:

Zitat von Stevie:

[...] 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 von neo4a:

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