AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Algorithmen, Datenstrukturen und Klassendesign Delphi Spring-DI / DelegatedConstructor / Factory für Dummies

Spring-DI / DelegatedConstructor / Factory für Dummies

Ein Thema von stahli · begonnen am 2. Feb 2012 · letzter Beitrag vom 15. Mär 2012
Antwort Antwort
Seite 5 von 10   « Erste     345 67     Letzte » 
Benutzerbild von BUG
BUG

Registriert seit: 4. Dez 2003
Ort: Cottbus
2.094 Beiträge
 
#41

AW: Spring-DI / DelegatedConstructor / Factory für Dummies

  Alt 13. Feb 2012, 17:16
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.
  Mit Zitat antworten Zitat
neo4a

Registriert seit: 22. Jan 2007
Ort: Ingolstadt
362 Beiträge
 
Delphi XE2 Architect
 
#42

AW: Spring-DI / DelegatedConstructor / Factory für Dummies

  Alt 13. Feb 2012, 17:17
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);
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.
Andreas
  Mit Zitat antworten Zitat
neo4a

Registriert seit: 22. Jan 2007
Ort: Ingolstadt
362 Beiträge
 
Delphi XE2 Architect
 
#43

AW: Spring-DI / DelegatedConstructor / Factory für Dummies

  Alt 13. Feb 2012, 17:20
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.
Andreas
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.336 Beiträge
 
Delphi 11 Alexandria
 
#44

AW: Spring-DI / DelegatedConstructor / Factory für Dummies

  Alt 13. Feb 2012, 17:28
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.

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

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 )
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
exilant

Registriert seit: 28. Jul 2006
134 Beiträge
 
Delphi 11 Alexandria
 
#45

AW: Spring-DI / DelegatedConstructor / Factory für Dummies

  Alt 13. Feb 2012, 17:38
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.
Anything, carried to the extreme, becomes insanity. (Exilant)
  Mit Zitat antworten Zitat
neo4a

Registriert seit: 22. Jan 2007
Ort: Ingolstadt
362 Beiträge
 
Delphi XE2 Architect
 
#46

AW: Spring-DI / DelegatedConstructor / Factory für Dummies

  Alt 13. Feb 2012, 17:41
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.
Andreas

Geändert von neo4a (13. Feb 2012 um 18:20 Uhr)
  Mit Zitat antworten Zitat
neo4a

Registriert seit: 22. Jan 2007
Ort: Ingolstadt
362 Beiträge
 
Delphi XE2 Architect
 
#47

AW: Spring-DI / DelegatedConstructor / Factory für Dummies

  Alt 13. Feb 2012, 17:44
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
Andreas

Geändert von neo4a (13. Feb 2012 um 19:07 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.007 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#48

AW: Spring-DI / DelegatedConstructor / Factory für Dummies

  Alt 13. Feb 2012, 20:11
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.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.336 Beiträge
 
Delphi 11 Alexandria
 
#49

AW: Spring-DI / DelegatedConstructor / Factory für Dummies

  Alt 13. Feb 2012, 20:41
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?
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)

Geändert von stahli (13. Feb 2012 um 23:36 Uhr) Grund: etwas klarer formuliert
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.007 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#50

AW: Spring-DI / DelegatedConstructor / Factory für Dummies

  Alt 13. Feb 2012, 23:28
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.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 13:44 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz