Spring-DI / DelegatedConstructor / Factory für Dummies

[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

[neo4a]

Zitat von stahli:

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.

Dieses Vorgehen wäre sowohl in der Praxis wie auch im Software-Design einfach falsch: So wie IMitarbeiter aus IEinkauf keine ITankdeckel aufzuschrauben hat, so sollte es z.B. IFuhrpark überlassen bleiben, die Menge an IKraftstoff zu ermitteln. Vielleicht ist ja noch ein IAuto unterwegs, dann müsste IEinkauf auch noch IFahrer kennen, den man anrufen müsste usw.

Besser und egal wie IFuhrpark intern aufgebaut und organisiert ist: IEinkauf fragt IFuhrpark.Leiter nach dem Bedarf an IKraftstoff. Ansonsten zieht jede (interne) Änderung in TFuhrpark möglicherweise eine Änderung der Prozedur TEinkauf.Bestellermittlung() nach sich: Wartungsaufwand und Fehleranfälligkeit steigt tendenziell.

(Zwischenteitlich hat Stefan vor mir mit ähnlichem Inhalt gepostet.)

[Uwe Raabe]

<ironie>
IPhone.Message(IMergency.Call(I.Self + ' habe versehentlich ' + ITank.Inhalt + ' in meinem ' + ITank.Name + ', weil ' + IDiot.Name + ' den ' + IMotor.Name + ' meiner ' + ISetta.Name + ' mit dem ' + ITank.Name + ' des ' + IVecoLKW.Name + ' verlinkt hat!'));
</ironie>

[neo4a]

Zitat von Uwe Raabe:

<ironie>
IPhone.Message(IMergency.Call(I.Self + ' habe versehentlich ' + ITank.Inhalt + ' in meinem ' + ITank.Name + ', weil ' + IDiot.Name + ' den ' + IMotor.Name + ' meiner ' + ISetta.Name + ' mit dem ' + ITank.Name + ' des ' + IVecoLKW.Name + ' verlinkt hat!')); </ironie>

Das kompiliert niemals!

[exilant]

Zitat von Stevie:

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?

Delphi-Quellcode:

case fuhrpark.eingeteiltesfahrzeug.motor.kraftoffart of
  diesel    : einkaufsabteilung.dieselbestellen;
  hafer     : einkaufsabteilung.haferbestellen;
  plutonium : sicherheitsdienst.anrufen;
end;

Denke ich zu einfach?

[exilant]

Zitat von neo4a:

Besser und egal wie IFuhrpark intern aufgebaut und organisiert ist: IEinkauf fragt IFuhrpark.Leiter nach dem Bedarf an IKraftstoff.

Im wirklichen Leben ist das nicht das auch nicht so. Da bekommt die Einkaufsabteilung die Anweisung von den Fachabteilungen zu Beschaffung der benötigten Materialien in der benötigten Menge. Müsste die Einkaufsabteilung pollen, würden sich unsere Einkäufer sofort erschießen.

[webcss]

Zitat von exilant:

Delphi-Quellcode:

case fuhrpark.eingeteiltesfahrzeug.motor.kraftoffart of
  diesel    : einkaufsabteilung.dieselbestellen;
  hafer     : einkaufsabteilung.haferbestellen;
  plutonium : sicherheitsdienst.anrufen;
end;

Denke ich zu einfach?

Antwort: Ja, den was machst Du wenn irgendwann Wasserstoff getriebene UBoote dazukommen?
Dann musst Du jedes case Konstrukt ändern.

Mit Interfaces hast Du dieses Problem nicht, Du übergibst einfach eine neue Klasse TUBoot (implementiert IFahrzeug), das war's...

[neo4a]

Zitat von exilant:

Zitat von neo4a:

Besser und egal wie IFuhrpark intern aufgebaut und organisiert ist: IEinkauf fragt IFuhrpark.Leiter nach dem Bedarf an IKraftstoff.

Im wirklichen Leben ist das nicht das auch nicht so. Da bekommt die Einkaufsabteilung die Anweisung von den Fachabteilungen zu Beschaffung der benötigten Materialien in der benötigten Menge. Müsste die Einkaufsabteilung pollen, würden sich unsere Einkäufer sofort erschießen.

Jetzt wird es langsam mühsam, da Du ausweichst und partiell und sinnenstellend quotest.

Aus meiner Sicht sind meine Argumente auf dem Tisch und es lohnt sich für mich nicht, in die nächste Wiederholschleife zu gehen.

Nimm Dir die Zeit und schau Dir die von Stefan bereits erwähnte CleanCodeDeveloper-Seite an. Damit bekommst Du einen schönen Blick darauf, wie und nach welchen Regeln die "großen Jungs" spielen.

[stahli]

Mein aktueller Meinungsstand:

Künftige Verwendung von Interfaces: UNBEDINGT!
Ebenso das Verbergen der Klassen-Units untereinander (im Regelfall).
Im Projekt sollen dann grundsätzlich nur die Schnittstellen bekannt sein.

Auf eine Verschachtelung von Objekten über deren Owner werde ich verzichten. Beziehungen untereinander werden über eine Property abgebildet, die die ID des referenzierten Objektes enthält.

Auf Spring werde ich (vorerst) verzichten und mir selbst eine "Factory" (oder wie müsste man das nennen?) bauen, die auf Anfrage Objekte erzeugt und deren Schnittstellen zurück liefert. Wird keine ID bei der Anforderung angegeben, wird eine neue erzeugt. Die ID besteht aus zwei Zeitstempeln und einem Zufallswert (Programmstartzeit und Now und Random) und dürfte damit weltweit nicht doppelt vorkommen und eindeutig nach der Erstellungsreihenfolge sortierbar sein (im Gegensatz zu einer GUID).
ID + Interface werden in einem Dictionary gespeichert (dadurch erhöht sich m.E. der RefCount).
Wird ein Interface eine gewisse Zeit nicht mehr abgerufen und der RefCount ist 1 wird es aus dem Dictionary entfernt (und das Objekt somit aufgelöst).

Ich könnte also sagen: IMyPerson := Factory.GetPerson(PersonId, InClubId);
Die Factory kümmert sich dann darum, die Objekte herauszusuchen bzw. ggf. zu erzeugen und ggf. die Verbindung zu anderen Objekten einzurichten und die Schnittstellen heraus zu geben.

Ich denke, das würde ich lieber selbst an zentraler Stelle regeln, anstatt Spring einzusetzen, von dem ich wenig verstehe.

Diesen Weg würde ich mir wünschen - wenn es so realisierbar ist. Ich könnte mir vorstellen, dass man damit sehr übersichtlich abeiten kann.


Weitere Überlegungen: (Ich bleibe mal hier im Thread, da das thematisch schon noch zusammen gehört.)

Die Daten jedes Objektes würden in einer einfachen DB gespeichert. Je Klasse eine Tabelle, je (mit Attribut gekennzeichneten) Property ein entsprechendes Feld. Die Tabellen können jederzeit anhand der Klassendefinition passend erzeugt werden.

Im Grunde wäre das ja schon ein kleiner ORM.

Oder sollte man dann doch lieber gleich zu mORMot oder DORM greifen und nicht alles neu erfinden? Aber die arbeiten wieder nicht mit Interfaces? Fragen über Fragen...

Letztlich geht es dann natürlich auch noch um die Datenbindung an die GUI. Bei meinem odControls habe ich alles fest verdrahtet. Jeder Tastendruck z.B. in einem odEdit hat sofort den Inhalt eines Propertys verändert. Es gibt also keine Transaktionen oder Prüfungen, die die Übergabe von Änderungen aus der GUI in die Datenebene kontrollieren.
Diesbezüglich muss ich mich dann doch mal genauer mit DSharp und LiveBinding auseinandersetzen.
Ich weiß, dass ich ohne ein Databinding nicht mehr arbeiten will. Wie genau, ist aber noch nicht entschieden.

Nachtrag: Die GUI-Controls müssten eigentlich eine ID und PropertyName zugewiesen bekommen und sich darauf hin aus der Factory das entsprechende Objekt abrufen und sich an dieses binden. An der Stelle wird man mit Interfaces sicher nicht weiter kommmen - oder? Oder kann die RTTI mit Interfaces genau wie mit Objekten umgehen?
Und wann sollen die GUI-Controls der Factory bescheid geben, dass die bereit gestellten Objekte/Interfaces wieder freigegeben werden können?
Oh Mann - sooo viele Fragen.

[ConstantGardener]

@stahli
...um die Verwirrung zu erhöhen schau dir auch mal das ORM (TMS Aurelius) von TMS Software an. Ist zwar nicht kostenfrei (wenn man zumindest kommerziell entwickelt) aber hat durch den DataModeller und der Möglichkeit seine Klassen aus der vorhandenen Datenbank zu generieren auch seinen Reiz. Datenbanken werden schon einige unterstützt und es werden mehr. Auch die restlichen Features sehen ganz nett aus. Ich spiele gerade ein wenig damit rum und bisher gefällt mir was ich sehe.

cu cg