Spring-DI / DelegatedConstructor / Factory für Dummies

[schlecki]

Zitat von Stevie:

Stell dir vor, du willst einkaufen. Du schaust in den Kühlschrank und siehst, was dir fehlt und notierst es. Du nimmst den Zettel und gehst in den Supermarkt. Dort kaufst du, was auf dem Zettel steht. Oder baust du deinen Kühlschrank ab, nimmst ihn mit in den Supermarkt und sagst denen: "Schauen sie mal rein, was ich brauche und füllen sie ihn auf"?

You made my day... Ich stelle mir grad den ein oder anderen (Ex-)Kollegen mit dem Kühlschrank im Supermarkt vor...

[neo4a]

Zitat von Stevie:

Oder baust du deinen Kühlschrank ab, nimmst ihn mit in den Supermarkt und sagst denen: "Schauen sie mal rein, was ich brauche und füllen sie ihn auf"? Das wär eine klassische Verletzung des LoD

Das ist aber m.E. nicht der Grund, weshalb der "intelligente Kühlschrank", der seine Waren automatisch nachordert, noch nicht so ganz in der Praxis angekommen ist.

Aber im Ernst: Ich nehme insbesondere den Kühlschrank nicht mit zum Einkauf, weil er immobil ist. Diese Beschränkung gibt es in der IT so nicht. Auch das klassische Beispiel mit der Geldbörse taugt immer weniger in Zeiten von Einzugsermächtigung und Co.

Wir brauchen wohl irgendwie eine bessere Herangehensweise, sonst gewinnt immer nur der mit der besseren Rhetorik.

[Stevie]

Zitat von neo4a:

Zitat von Stevie:

Oder baust du deinen Kühlschrank ab, nimmst ihn mit in den Supermarkt und sagst denen: "Schauen sie mal rein, was ich brauche und füllen sie ihn auf"? Das wär eine klassische Verletzung des LoD

Das ist aber m.E. nicht der Grund, weshalb der "intelligente Kühlschrank", der seine Waren automatisch nachordert, noch nicht so ganz in der Praxis angekommen ist.

Und auch in diesem Fall würde der "intelligente Kühlschrank" nur eine Warenliste übermitteln und nicht selber in den Supermarkt rollen oder?

Zitat:

Aber im Ernst: Ich nehme insbesondere den Kühlschrank nicht mit zum Einkauf, weil er immobil ist. Diese Beschränkung gibt es in der IT so nicht. Auch das klassische Beispiel mit der Geldbörse taugt immer weniger in Zeiten von Einzugsermächtigung und Co.

Wir brauchen wohl irgendwie eine bessere Herangehensweise, sonst gewinnt immer nur der mit der besseren Rhetorik.

Und auch eine Einzugsermächtigung übergibt nur die benötigten Daten und nicht deine Kreditkarte inklusive Pinnummer, damit der Gegenüber selber das Geld abheben kann.

[neo4a]

Stefan,

Deine Einwände sind völlig korrekt und ich teile Deine Sicht, ganz klar.

Es gibt aus aus meiner Sicht trotzdem einen fundamentalen Unterschied zwischen den noch so einleuchtenden Praxis-Beispielen und den Methoden in der IT: Wer ist der "Herr der Informationen"? Das, was sich in der Praxis von selbst verbietet, kann im Software-Design als besonders elegant angesehen werden: Wenn ich gleich Zugriff auf sämtliche Stammdaten habe, brauche ich nicht erst jedesmal zu fragen. ("Da schreibe ich mir ja die Finger wund.") - Mir erscheint manchmal ohnehin der zusätzliche Schreibaufwand bei der Interface-Deklaration als häufigstes Hindernis für deren Einsatz.

Wenn ich allerdings als Entwickler A verantwortlich bin für die Konsistenz meiner Stammdaten, lasse ich den Entwickler B nicht mehr so ohne weiteres in meinem Bereich rumwerkeln. Da mache ich zu und tausche nur das aus, was ich verantworten kann. Diese Konstellation und Sichtweise erschließt sich nicht jedem, insbesonderen dem nicht, der sich als "Herr aller Daten" sieht.

[stahli]

Sehe ich auch so. Eine strikte und klare Trennung macht oft sehr viel Sinn, ist aber manchmal auch unnötig.

Z.B. würde man die Panel.Font-Eigenschaften nicht direkt im Panel veröffentlichen. Wozu auch? Man kann zwar argumentieren, dass das logischer wäre, aber es wäre ein Aufwand, der letzlich keinen wirklichen Nutzen bringt.
Außerdem müsste man dann konsequenter Weise auch die Canvas-Propertys usw. direkt im Panel veröffentlichen. Das macht nicht wirklich Sinn.

Man muss sich also in jedem Anwendungsfall für die beste Verfahrensweise entscheiden. Dass man dabei die Grundlagenb (LoD usw.) berücksichtigt, ist natürlich sinnvoll.

Im Beispiel dest Kaftstoffs würde ich in der Realität im Handbuch des Fahrzeugs nachsehen, was ich tanken muss oder andere fragen oder in einer Tabelle nachlesen. Das lässt sich in der Software so nicht sinnvoll nachbilden. Jedenfalls nicht, um lediglich die Tankstofffrage zu klären.
Also entgegen der Realität ist es in dem Fall am einfachsten, den Motor zu fragen, was er denn tanken will. Wie man das im Detail realisiert (ob man direkt Auto.Motor.Kraftstoff anspricht oder die Abfrage in einer Funktion Auto.GetKraftstoff kapselt) und ob man dabei mit Objekten oder Interfaces arbeitet, ist dabei m.E. nebensächlich.

Insofern ist das ein anderes Thema, das zwar durchaus wichtig ist, aber nicht in aller Konsequenz durchgedrückt werden sollte.

Für mich ist die Frage interessanter, wie die Objekte (deren Schnittstellen weiter verwendet werden) ertzeugt und verwaltet werden.
Wer ist Owner der Objekte? Gibt es Verschachtelungen? Wer kümmert sich um die Lebensdauer der Objekte?


Im Moment schlage ich mich mit eingen Seiteneffekten herum, die sich gelegentlich bei meinen Objekt-Verwaltungen und den komplexen Beziehungen ergeben. Dabei verspreche ich mir Verbesserungen bei der künftigen Verwendung von Schnittstellen und einer zentralen Objekterzeugung.
Im Moment muss ich aber erst nochmal die Kühe einfangen.

Wenn man auf die Owner-Verkettung verzichtet, muss man die Beziehungen der Objekte natürlich anders abbilden. Aktuell kann ich für tausend Objekte einfach das OwnerTournament interativ ermitteln.
Ohne diese verschachtelung müsste ich für die tausend Objekte eine neue Eigenschaft einführen, die auf das Tournament-Objekt verweist. Führe ich das als Pointer aus, mag das noch gehen. Speichere ich aber die (ggf. lange) Id, geht das auf den Speicherverbrauch.

Das sind die "Probleme", die mir aktuell noch Kopfzerbrechen bereiten...

[exilant]

Zitat von Stevie:

Zitat von BUG:

Zitat von exilant:

Delphi-Quellcode:

//
if fuhrpark.eingeteiltesfahrzeug.motor.kraftoffart = diesel then einkaufsabteilung.dieselbestellen;

Schon bei der Lesbarkeit macht das Unterschiede.

Delphi-Quellcode:

//
einkaufsabteilung.bestelle(fuhrpark.ermittleBedarf());

Abgesehen könnte der Fuhrpark jetzt Pferdekarren unterstützen, die Hafer verbrauchen, ohne den Code ändern zu müssen.

Der Post trifft den Nagel so sehr auf den Kopf, dass ich ihn nochmal betonen möchte. Die Lösung sorgt nicht nur dafür, dass das LoD eingehalten wird. Sie ist auch so flexibel, dass es dem Interface (in diesem Fall den beiden genannten Methoden) egal ist, wie es intern aus sieht (ob nun Diesel oder Hafer bestellt wird) und sie kann noch für andere Zwecke gebraucht werden (der aktuelle Bedarf kann über Reporting gedruckt werden, oder man kann Statistiken über Durchschnittsverbrauch oder sonstwas aufstellen).

Das alles geht bei dem Originalcode nicht.

Wie ich bereits sagte, wenn man einen DI Container benutzen möchte sollte man das nicht tun, bevor man so einige Prinzipien und dessen Nutzen größtenteils verinnerlicht hat, sonst hat man immer dieses "wofür mach ich mir diese 'Mühe'"-Gefühl.

Mit Verlaub: Da wird imo nichts auf den Kopf getroffen. Du wirst eine Stelle haben an der festzustellen ist ob der Motor Diesel oder Hafer frisst. Das ist der Punkt. Und die Einkaufsabteilung wird zu irgendeinem Zeitpunkt erfahren müssen ob sie Superbenzin oder Kerosin beschaffen muss. Das sollte diese "Codezeile" verdeutlichen. Und genau das meine ich mit der Behauptung vom "Mythos der Entkopplung". Zu treffende Entscheidungen hängen an den Entitäten und ihren konkreten Eigenschaften. Ihre Komplexität kann nicht durch "Umverteilung" elemeniert werden.

[exilant]

Wo wir so schön dabei sind:

Zitat von Stevie:

In dem Codeschnipsel ging es um das bestellen von Treibstoff. Was hat das Bestellen von Treibstoff mit der Kenntnis des Fuhrparks und deren Motoren zu tun? Richtig, nix.

Kein Mensch behauptet, dass die Einkaufsabteilung Kenntnis über den Fuhrpark haben muss. Dass kannst du der einen Pseudocodezeile auch klar entnehmen: Da heisst es "einkaufsabteilung.dieselbestellen".
Und wie sie der Anweisung Diesel zu bestellen nachzukommen hat, sollte sie durchaus wissen.
Der Herr des Fuhrparkes muss aber detaillierte Informationen über die Objkete in seiner Verwaltungsdomäne haben. Er hat festzustellen wieviel Hafer, Kerosin und Plutonium (für den Flux Kompensator vom DeLoran des Chefs) die Einkaufsabteilung zu beschaffen hat. Bei der ganzen Sache ging es doch ursprünglich um Verletzungen von LoD. Die liegt um Ursprungspost vor, aber ich kann nichts schlimmes daran entdecken.

[neo4a]

Zitat von exilant:

Und die Einkaufsabteilung wird zu irgendeinem Zeitpunkt erfahren müssen ob sie Superbenzin oder Kerosin beschaffen muss.

Dazu muss sie den TAutos = TInterfacedList<IAuto> aber nicht in den ITank gucken können. Das macht vielleicht der (hoffentlich entkoppelte) FFuhrparkleiter = IFuhrparkleiter

[exilant]

Zitat von stahli:

Also entgegen der Realität ist es in dem Fall am einfachsten, den Motor zu fragen, was er denn tanken will. Wie man das im Detail realisiert (ob man direkt Auto.Motor.Kraftstoff anspricht oder die Abfrage in einer Funktion Auto.GetKraftstoff kapselt) und ob man dabei mit Objekten oder Interfaces arbeitet, ist dabei m.E. nebensächlich.

Puh. Er versteht mich.

Zitat von stahli:

Für mich ist die Frage interessanter, wie die Objekte (deren Schnittstellen weiter verwendet werden) ertzeugt und verwaltet werden.
Wer ist Owner der Objekte? Gibt es Verschachtelungen? Wer kümmert sich um die Lebensdauer der Objekte?

Meine Welt besteht fast komplett aus typisierten Objektlisten. Objekte die potentiell Property verschiedener anderer Objekte sein können haben ein property "userlist". Ihr Owner (immer eine typisierte Liste) implementiert eine cleanup Methode welche Items mit userlist.count=0 freigibt. Die cleanup methode wird aufgerufen, wenn ein neues Objekt von der Liste verlangt wird. Dort werden die Objekte auch erzeugt.

Beispiel (stark vereinfacht):

methode fuhrpark.fahrzeug(ckennz:string):tfahrzeug;
CleanupInterneListe(cKennz);
result := HolefahrzeugAusInternerListe(ckennz);
if result = NIL then result := erzeugeFahrzeug(ckennz);
InterneListe.add(result);
end;


und wo ein Fahrzeug benötigt wird:

Einsatzfahrzeuge.add(fuhrpark.fahrzeug('K-BW-5050'))


// implementiert ungefähr so:

methode EinsatzFahreuge.add(kfz:tfahrzeug)
ffahrzeuge.add(kfz);
kfz.adduser(self);
end

destructor Einsatzfahrzeuge.destroy;
RemoveMefromProperties;
ffahrzeuge.free;
inherited;
end

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