Spring-DI / DelegatedConstructor / Factory für Dummies

[stahli]

@neo4a (mit etwas Verspätung wegen zeitw. Netzausfall)

Sie sieht eben doch in jedem Fall in dem Tank nach.
Allerdings eben über eine gewissermaßen annonyme Funktion. Sie weiß nicht, dass sie im Tank nachsieht, macht es aber eben doch.

Wenn TObject bereits eine Property "Kraftstoff" hätte, deren Getter nach belieben überschrieben werden könnte, würde Eure Argumentation eigentlich schon überflüssig werden. Dann hätte man über eine Schnittstelle nicht viel gewonnen.

Wenn völlig verschiedene Klassen "Kraftstoff" einführen macht die Verwendung einer Schnittstelle schon Sinn, damit man die Objekte bei der Kraftstoffberechnung nicht extra casten muss.

Irgendwie wirkt das Ganze aber teilw. wie eine Metadiskussion auf mich.
Die zwei genannten Funktionen könnte man auch auf klassischem Wege realisieren. Die Kraftstoffermittlung (die könnte auch in eine gesonderte Unit ausgelagert werden) müsste die in Frage kommenden Klassen natürlich kennen, aber der Aufruf
einkaufsabteilung.bestelle(fuhrpark.ermittleBedarf()); könnte eigentlich genau so aussehen.

Ich hätte gern detailliertere Aussagen. Vielleicht wird man sich ja dann doch noch einig.


@exilant

So etwa arbeite ich auch. Aber die Beziehungen sind sehr komplex geworden. Daher verspreche ich mir durch eine zentrale Objekteverwaltung und Arbeit mit Schnittstellen eine bessere Übersicht.