Spring-DI / DelegatedConstructor / Factory für Dummies

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