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.

[neo4a]

Zitat von exilant:

Zitat von BUG:

Meine Lösung wäre:
Der Fuhrparkleiter fragt das Auto, was es für Sprit will, das fragt den Motor und der muss es schließlich wissen.

Klar. Das geht. Nur warum ist

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

schlechter Stil? Genau das behauptet Demeter.

eingeteiltesfahrzeug implementiert IAuto. Über IAuto erfährt man die Kraftstoffart. (TAuto hat intern über seinen Member FMotor : IMotor Zugriff auf das Interface IMotor und die Kraftstoffart.)

Also vielleicht so:

Delphi-Quellcode:

 aAuto : IAuto
 aDieselMenge : Integer; 
var
  aDieselMenge := 0;
  for aAuto in aFuhrpark do
   if aAuto.Kraftstoffart = cDiesel then 
     inc(aDieselMenge, aAuto.Tankgroesse);

  einkaufsabteilung.bestellen(cDiesel, aDieselMenge);

Zitat von exilant:

Entkopplung ist Mythos. Als Ausnahme lasse ich in der Tat nur die Entkopplung von GUI/BL gelten. Und auch da nur bedingt.

Entkopplung funktioniert schon und mit Spring ohne große Klimmzüge. Es ist für Delphi neu und vielleicht auch ungewohnt, wenn man bisher anders erfolgreich war.

[neo4a]

Zitat von Jens01:

Ja, dann funktioniert es für die Liste aber nicht mehr innerhalb von TAuto.

Wenn Du meine beiden Hinweise berücksichtigt hast und Du immer noch Probleme feststellst, musst Du noch einmal zeigen, an welcher Stelle im Code es hakt.

[stahli]

Zitat von Jens01:

Ja, da ist für TAuto auch richtig, da es im Auto auch nur einen Motor gibt.

Singelton bezieht sich aber (sicherlich) auf das globale Projekt. Du würdest also in jedes Auto exakt den selben einen Motor einbauen - was natürlich physisch nicht möglich ist. Man muss also jeweils eine Motorinstanz erzeugen und dessen Interface dann weiter verwenden. Die Frage ist dann für mich, wer Owner des erzeugten Objektes (dessen verwendete Schnittstelle verwendet wird) ist.

Zitat von Jens01:

Ja, dann funktioniert es für die Liste aber nicht mehr innerhalb von TAuto.

Im Auto gibt es auch nur einen Platz für einen Motor. Dem kannst Du dann einen IMotor oder einen ITestMotor zuweisen (oder ggf. auch erst mal keinen).

Zitat von exilant:

Klar. Das geht. Nur warum ist
if fuhrpark.eingeteiltesfahrzeug.motor.kraftoffart = diesel then einkaufsabteilung.dieselbestellen;
schlechter Stil?

Das hat aber nichts mit Interfaces und Spring zu tun. Man kann technisch auf Fahrzeug.Motor.Kraftstoffart zugreifen, egal ob Motor vorliegend ein Objekt oder Interface ist.
Wichtig ist hier natürlich, dass bei jedem Zugriff auf Motor.Kraftstoffart ein Motor zugewiesen ist. Ist das nicht gesichert, muss man den Zugriff natürlich in einer Eigenschaft oder Funktion kapseln.
Aber wie der Motor erstellt und und in das Fahrzeug eingebaut wird, ist dabei völlig egal.
Einziger Aspekt: Wenn Motor eine Klasseninstanz ist, kennt das Auto alle öffentlichen Eigenschaften und Methoden des Autos (also Schraubenanzahl, Kraftstoffart sowie die Methode Brumm). Handelt es sich um eine Schnittstelle, dann kennt das Auto nur die dort veröffentlichten Eigenschaften (also z.B. nur die Kraftstoffart). Dann könnte man irgendwann auch mal etwas anders als einen Motor einbauen, das eine Kraftstoffart benennen kann (z.B. einen Kanister - macht aber wohl nicht viel Sinn )

[exilant]

Zitat von neo4a:

Entkopplung funktioniert schon und mit Spring ohne große Klimmzüge. Es ist für Delphi neu und vielleicht auch ungewohnt, wenn man bisher anders erfolgreich war.

Möglicherweise ist das so. Ich werde darum auch weiter am Ball bleiben und meinen Code sehr genau betrachten. Entwickler sollten schließlich nicht ignorant sein. Bisher haben mich allerdings weder die hier noch die an anderer Stelle beschriebenen Beispiele überzeugt oder auch nur beeindruckt.

[neo4a]

Zitat von exilant:

Klar. Das geht. Nur warum ist
if fuhrpark.eingeteiltesfahrzeug.motor.kraftoffart = diesel then einkaufsabteilung.dieselbestellen;
schlechter Stil?

Zitat:

Das hat aber nichts mit Interfaces und Spring zu tun. Man kann technisch auf Fahrzeug.Motor.Kraftstoffart zugreifen, egal ob Motor vorliegend ein Objekt oder Interface ist.
Wichtig ist hier natürlich, dass bei jedem Zugriff auf Motor.Kraftstoffart ein Motor zugewiesen ist. Ist das nicht gesichert, muss man den Zugriff natürlich in einer Eigenschaft oder Funktion kapseln.
Aber wie der Motor erstellt und und in das Fahrzeug eingebaut wird, ist dabei völlig egal.

Man kann es sogar noch weiter treiben: Beim Tanken ist es völlig egal, ob überhaupt ein Motor eingebaut ist. Damit ist klar: Ein "Durchgreifen" auf Eigenschaften und Methoden sollte vermieden werden.

[neo4a]

Zitat von exilant:

Bisher haben mich allerdings weder die hier noch die an anderer Stelle beschriebenen Beispiele überzeugt oder auch nur beeindruckt.

In Deinen Antworten waren bislang noch einige konzeptionelle Missverständnisse zu erkennen.

BTW, niemand will Dich beeindrucken, schließlich ist das hier keine Verkaufsveranstaltung, nicht wahr

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