Spring-DI / DelegatedConstructor / Factory für Dummies

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

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

[stahli]

Darf ich da nochmal nachhaken?

einkaufsabteilung.bestelle(fuhrpark.ermittleBedarf()); "Bestelle" tut irgend etwas mit den Einträgen einer Liste, die "ErmittleBedarf" bereit stellt (5 Liter Diesel, 2 kg Hafer).
So weit richtig?

Sofern es ein Ökoauto als Ableitung von Auto gäbe (EDIT: "welches mit Hafer fährt"), könnte ich das mit Objekten genau so regeln.

Der Vorteil von Interfaces kommt in´s Spiel, wenn der Hafer-Verbraucher nicht von Auto abgeleitet ist.

Dann müsste ich bei der Arbeit mit unterschiedlichen Objekten (verschiedenen Basisklassen) in ErmittleBedarf alle Einträge des Fuhrparks casten, um die gleichen Ergebnisse zu ermitteln.
Das ist etwas umständlich und nicht sehr elegant und der Fuhrpark muss alle potentiellen Klassen genau kennen (die entsprechenden Units einbinden).

Insofern ist es schon anzustreben, Interfaces zu verwenden - das sehe ich ein.


Aber Deine zusätzlichen Hinweise über die flexible Anwendungsmöglichkeit kann ich (noch) nicht nachvollziehen.
Mit normalen Objekten ginge das doch auch - wenn auch mit mehr Aufwand.

Sehe ich das richtig? Oder was sehe ich falsch?

[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.
Das zuständige Personal bekommt mitgeteilt, was gebraucht wird und kümmert sich um alles weitere. Ob die dann Rabatte aushandeln, Buchhaltung pflegen etc pp braucht nicht mehr zu interessieren. Wichtig ist: genau die Daten, welche gebraucht werden, werden übergeben - in diesem Fall Spritmengen - nicht mehr und nicht weniger.

Ich kann nur aus eigener Erfahrung sagen - versteifts euch nicht so auf nen DI Container, oder Interfaces (also die in Delphi), sondern versucht, solche Dinge zu verinnerlichen, die es erst ermöglichen, erweiterte Techniken anzuwenden. Und auch hier muss gesagt werden, es muss nicht überall ein DI Container sein - in vielen Fällen reicht es schon die Prinzipien, die dahinter stecken "manuell" anzuwenden.

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"? Das wär eine klassische Verletzung des LoD und wenn man die in die Beispiele aus der Realität umsetzt, merkt man, wie albern der Code eigentlich ist, den man oftmals schreibt - ich schließe mich da nicht aus. In den Beispiel oben könntest du aber auch den Einkaufszettel jemandem aus der Familie geben und den Einkaufen schicken und das Ergebnis wäre am Ende das gleiche: ein wieder gefüllter Kühlschrank.

Das wichtige ist also eine klare Definition der Schnittstellen ohne bestimmte Grenzen und Zuständigkeitsbereiche zu überschreiten.

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

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

[Stevie]

Zitat von 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.

Und genau hier trennen sich unsere Ansichten. Wo befinde ich mich denn bei dieser Codezeile?

Code:

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

Sie hat Kenntnis von Fuhrpark, Fahrzeug und Motor (durch den Zugriff auf die Properties) und greift somit 3 Ebenen tief in die Struktur. Desweiteren ist sie auf eine Kraftstoffart festgeschrieben. Für Benzin, Hafer, Plutonuium müsste eine ähnliche Zeile her -> Copy and Paste?

Jedwede Änderung an allen zuvor genannten Beteiligten könnte zur Folge haben, dass dieser Code nicht mehr korrekt funktioniert. Annahmen über die Struktur indirekter Abhängigkeiten erzeugt eine direkte Abhängigkeit.

Den Kraftstoffbedarf zu ermitteln wäre somit ein internes Implementierungsdetail von Fuhrpark. Ob der Fuhrparkleiter dann in den Fahrzeugscheinen nachschaut, nen Schlauch in die Tanks steckt oder dem Azubi sagt, er soll mal rumlaufen und auf die Tanknadel schauen, ist total Rille für denjenigen, der gerne den Kraftstoffbedarf mitgeteilt haben möchte.

Stichwort: Tell, don't ask