Spring-DI / DelegatedConstructor / Factory für Dummies

[BUG]

Zitat:

Zitat von exilant (Beitrag 1150841)

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:

Zitat von exilant (Beitrag 1150841)

Zitat:

Zitat von BUG (Beitrag 1150821)

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:

Zitat von exilant (Beitrag 1150841)

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:

Zitat von Jens01 (Beitrag 1150845)

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:

Zitat von Jens01 (Beitrag 1150845)

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:

Zitat von Jens01 (Beitrag 1150845)

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:

Zitat von exilant (Beitrag 1150841)

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:

Zitat von neo4a (Beitrag 1150855)

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:

Zitat von exilant (Beitrag 1150841)

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:

Zitat von exilant (Beitrag 1150865)

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:

Zitat von BUG (Beitrag 1150854)

Zitat:

Zitat von exilant (Beitrag 1150841)

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?

Delphi-Quellcode:

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. :-D


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:

Zitat von Stevie (Beitrag 1150925)

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... :twisted:

[neo4a]

Zitat:

Zitat von Stevie (Beitrag 1150925)

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:

Zitat von neo4a (Beitrag 1150952)

Zitat:

Zitat von Stevie (Beitrag 1150925)

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:

Zitat von Stevie (Beitrag 1150891)

Zitat:

Zitat von BUG (Beitrag 1150854)

Zitat:

Zitat von exilant (Beitrag 1150841)

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.

Mit Verlaub: Da wird imo nichts auf den Kopf getroffen. Du wirst eine Stelle haben an der festzustellen ist ob der Motor Diesel oder Hafer frisst. Das ist der Punkt. Und die Einkaufsabteilung wird zu irgendeinem Zeitpunkt erfahren müssen ob sie Superbenzin oder Kerosin beschaffen muss. Das sollte diese "Codezeile" verdeutlichen. Und genau das meine ich mit der Behauptung vom "Mythos der Entkopplung". Zu treffende Entscheidungen hängen an den Entitäten und ihren konkreten Eigenschaften. Ihre Komplexität kann nicht durch "Umverteilung" elemeniert werden.

[exilant]

Wo wir so schön dabei sind:

Zitat:

Zitat von Stevie (Beitrag 1150925)

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.

[neo4a]

Zitat:

Zitat von exilant (Beitrag 1150990)

Und die Einkaufsabteilung wird zu irgendeinem Zeitpunkt erfahren müssen ob sie Superbenzin oder Kerosin beschaffen muss.

Dazu muss sie den TAutos = TInterfacedList<IAuto> aber nicht in den ITank gucken können. Das macht vielleicht der (hoffentlich entkoppelte) FFuhrparkleiter = IFuhrparkleiter ;)

[exilant]

Zitat:

Zitat von stahli (Beitrag 1150981)

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:

Zitat von stahli (Beitrag 1150981)

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

Delphi-Quellcode:

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.

[Stevie]

Zitat:

Zitat von exilant (Beitrag 1150994)

Wo wir so schön dabei sind:

Zitat:

Zitat von Stevie (Beitrag 1150925)

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:

Zitat von stahli (Beitrag 1151015)

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>

Delphi-Quellcode:

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:

Zitat von Uwe Raabe (Beitrag 1151066)

<ironie>

Delphi-Quellcode:

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:

Zitat von Stevie (Beitrag 1151025)

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:

Zitat von neo4a (Beitrag 1151028)

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:

Zitat von exilant (Beitrag 1151077)

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:

Zitat von exilant (Beitrag 1151078)

Zitat:

Zitat von neo4a (Beitrag 1151028)

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

[exilant]

Zitat:

Zitat von neo4a (Beitrag 1151082)

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.

Ich werde mit deiner Verachtung leben müssen und weiter als kleiner Junge jeden Tag Probleme lösen. Ich werde die Augen offenhalten und sehen, welche Werkzeuge es so gibt die mir das Leben leichter machen. Was cleancodedeveloper.de angeht:
Das mit den Armbändchen ist doch Satire, oder?

[stahli]

Zitat:

Zitat von ConstantGardener (Beitrag 1151217)

@stahli
...um die Verwirrung zu erhöhen schau dir auch mal das ORM (TMS Aurelius) von TMS Software an...

Da hoffe ich auf weniger Verwirrung und dann SOWAS! ;-)
Aber danke für die Info. Das sieht auf den ersten Blick sehr umfangreich aus. Werde ich mir mal die Tage anschauen...
(Der Kauf wäre notfalls machbar.)

[ConstantGardener]

@stahli

Das täuscht. :-D Man kommt recht schnell zu Ergebnissen. Ich hatte mir ein kleines ORM auf Basis der neuen RTTI schon selbst gebastelt. Funktionierte auch recht gut (Spalten mit Attributen benennen, SQL aus diesen dann generieren usw.) und war als Training für RTTI super. Brunos Jungs habe hier aber schon einiges mehr aufgebaut (Linq-like-Syntax Querys usw.). Super ist auch die Unterstützung der verschiedenen DB's. Da bekommt man Lust auf mehr.

[stahli]

Ich meinte mit "umfangreich" nicht unbedingt "besonders kompliziert" sondern eher "viele Möglichkeiten". Auch gerade wegen der Linq-Syntax.

Vorhin habe ich nochmal schnell die Dokumentationen zum Aurelius und DataModeller durchgeblättert. Das scheint schon sehr leistungsfähig zu sein, ist aber zwangsläufig auch recht DB-lastig.
Ich meine, man muss sich auch mit den DB detailliert auseinandersetzen.

Nach meinen Überlegungen hätte ich aus den Klassen einfach vorläufige Tabellen generiert, in denen die Daten abgelegt werden (also keine direkten relationen Beziehungen, Trigger usw).
Man müsste sich also letztlich nur um die Klassen und Interfaces kümmern und die DB würde als reines (dummes) Datenlager dienen.

Natürlich ist so ein ausgewachsenes ORM deutlich leistungsfähiger.
Allerdings arbeitet man dann ja auch wieder mit Objekten. Würde das Aureliius-Framework klaglos ermöglichen, da Schnittstellen zu implementieren?
Auch möchte ich gern mit generischen Listen arbeiten. Harmoniert das dann?

Und letztlich ist mir wichtig, dass sich die GUI-Controls selbständig dynamisch die Objekte/Interfaces abrufen können, deren Daten sie binden sollen. Etwa so:

Delphi-Quellcode:

EditFirstName.Interface := IMyPerson;
EditFirstName.PropName := 'FirstName';

//oder auch

EditFirstName.Interface := IMyPlayer;
EditFirstName.PropName := 'Person.FirstName'; // wobei intern auf das Personenobjekt aufgelöst wird

In der Form nutze ich das bei meinen odControls und möchte das gern beibehalten.
Allerdings werden derzeit alle genutzen Datenobjekte dauerhaft im Speicher gehalten, was ich künftig nicht mehr will.

Vermeiden möchte ich, beim Öffnen eines Formulars dutzende Objekte/Interfaces zu erzeugen und die dann an die Formularcontrols zu binden.
Statt dessen weise ich lieber (wie auch jetzt schon) nur das oberste Objekt zu und das Framework kümmert sich darum, alle weiteren Subobjekte/Interfaces zu laden und an die Formularcontrols zu binden.

Ich werde wohl in nächster Zeit mal einige Varianten testen müssen, bin aber an allen Diskussionen zu diesem Bereich weiterhin brennend interessiert.

[Stevie]

Zitat:

Zitat von exilant (Beitrag 1151222)

Zitat:

Zitat von neo4a (Beitrag 1151082)

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.

Ich werde mit deiner Verachtung leben müssen und weiter als kleiner Junge jeden Tag Probleme lösen. Ich werde die Augen offenhalten und sehen, welche Werkzeuge es so gibt die mir das Leben leichter machen. Was cleancodedeveloper.de angeht:
Das mit den Armbändchen ist doch Satire, oder?

Wieder ein Bestätigung, warum Delphi Entwickler des öfteren mit einem müden Lächeln und einem "das gibt's noch?" abgetan werden.

P.S.: Ob du dir Armbändchen anziehst oder nicht, oder, wenn du Judo oder Karate machst, nen Gürtel umbindest, steht dir frei. Und auch, ob du dazulernen willst, oder nicht.

[Phoenix]

Zitat:

Zitat von exilant (Beitrag 1151222)

Was cleancodedeveloper.de angeht:
Das mit den Armbändchen ist doch Satire, oder?

Nein. Das ist lediglich ein erprobtes Mittel um sich selber immer wieder daran zu erinnern das man versuchen sollte sauberen Code zu schreiben.

Hintergrund der ganzen Sache ist eigentlich das Buch "Clean Code" von Robert "Uncle Bob" Martin. Natürlich kann man nicht alles davon auf die Goldwaage legen, aber es zeigt an vielen Beispielen wieso man Code besser nicht auf eine bestimmte, unschöne/unsaubere Art schreibt. Ich glaube die schlechten Beispiele in dem Buch sind hervorragende Dinge um einen Entwickler der ein bisschen auf Wartbarkeit wert legt aufzuschrecken und zu sensibilisieren.

[neo4a]

Zitat:

Zitat von exilant (Beitrag 1151222)

Zitat:

Zitat von neo4a (Beitrag 1151082)

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.

Ich werde mit deiner Verachtung leben müssen und weiter als kleiner Junge jeden Tag Probleme lösen.

Irgendwie habe ich Deine Antwort gestern hier übersehen. Egal: Von Verachtung meinerseits kann überhaupt nicht die Rede sein. Wenn das bei Dir so angekommen sein sollte, tut mir das Leid. Ich dachte, die gequoteten "großen Jungs" brauchen keinen zusätzlichen Smiley mehr.

Sobald man die nunmehr nur noch kleine (heile?) Welt von Delphi verlässt und sich mit anderen Sprachen und Plattformen beschäftigt/beschäftigen muss, kommt man mit einer Reihe von Methoden und Konzepten in Berührung, die quasi Industriestandard sind. Libs wie Delphi-Spring und Stefans D# erlauben es, sich in sie in vertrauter Delphi-Umgebung einzuarbeiten und seine bisherige Herangehensweise kritisch zu hinterfragen allein durch die Frage: Wie machen's denn die anderen? Und wenn sich Leute wie Googles verantwortlicher Test-Manager Misko Hevery z.B. zu CleanCode/testable Code äußern und sich dabei in die Karten schauen lassen, dann sind das für mich die "großen Jungs" aus der Praxis.

[exilant]

Zitat:

Zitat von Stevie (Beitrag 1151309)

Wieder ein Bestätigung, warum Delphi Entwickler des öfteren mit einem müden Lächeln und einem "das gibt's noch?" abgetan werden.

Weil ich bunte Armbänder für Satire halte? Das Buch von Robert Martin habe ich mir erstmal bestellt. Die Zielrichtung von cleancode finde ich löblich. Ettliche der dort propagierten Grundsätze bemühe ich mich schon seit langem einzuhalten. Ich werde aber genausowenig bunte Armbänder tragen wie ich irgendwelche Manifestos unterzeichne. Das geht mit verlaub dann doch in Richtung Religion und Psycho-Quatsch.

[neo4a]

Zitat:

Zitat von exilant (Beitrag 1151327)

Die Zielrichtung von cleancode finde ich löblich. Ettliche der dort propagierten Grundsätze bemühe ich mich schon seit langem einzuhalten.

Dann werden Dich viele der deutsch/englischen Gedanken und Anregungen hier (insbesondere zu agiler Entwicklung und Test) vielleicht auch interessieren. Aus meiner Sicht ist das eine Fundgrube und geschrieben von einem ganz erfahrenen Praktiker.

[exilant]

Zitat:

Zitat von neo4a (Beitrag 1151316)

Und wenn sich Leute wie Googles verantwortlicher Test-Manager Misko Hevery z.B. zu CleanCode/testable Code äußern und sich dabei in die Karten schauen lassen, dann sind das für mich die "großen Jungs" aus der Praxis.

Zweifellos gibt es ganz andere Ligen als die in der ich spiele. Ich baue/warte eine kleines Mietshaus, nicht Stuttgart21. Um mit Marx zu sprechen: Das Sein bestimmt das Bewusstsein. Google hat andere Sorgen als ich.