Spring-DI / DelegatedConstructor / Factory für Dummies

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

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

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