-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by neo4a,
16. Feb 2012
Meinetwegen. Dann darfst Du halt nicht Marx zitieren, denn das Zitat bezieht sich im Hegelschen Sinne auf dialektische Zusammenhänge und nicht auf (D)eine Wahrnehmungsfähigkeit. ;)
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by neo4a,
16. Feb 2012
Das Zitat passt sehr gut, doch Deine rhetorischen Schlüsse daraus (wieder einmal) nicht. Was Du meinst ist: "Schuster bleib bei Deinen Leisten".
Tatsächlich befinden wir uns in einem dialektischen Spannungsfeld: "Durch den Widerspruch zwischen wachsenden Bedürfnissen der Menschen und der niedrigen Produktivität kommt es zur Erfindung von Maschinen." Das auf die IT-Belange angepasst ist das,...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by neo4a,
16. Feb 2012
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.
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by neo4a,
16. Feb 2012
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...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by neo4a,
14. Feb 2012
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...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by neo4a,
14. Feb 2012
Das kompiliert niemals! ;)
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by neo4a,
14. Feb 2012
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...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by neo4a,
14. Feb 2012
Dazu muss sie den TAutos = TInterfacedList<IAuto> aber nicht in den ITank gucken können. Das macht vielleicht der (hoffentlich entkoppelte) FFuhrparkleiter = IFuhrparkleiter ;)
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by neo4a,
14. Feb 2012
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...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by neo4a,
14. Feb 2012
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...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by neo4a,
13. Feb 2012
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 ;)
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by neo4a,
13. Feb 2012
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.
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by neo4a,
13. Feb 2012
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.
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by neo4a,
13. Feb 2012
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:
aAuto : IAuto
aDieselMenge : Integer;
var
aDieselMenge := 0;
for aAuto in aFuhrpark do
if aAuto.Kraftstoffart = cDiesel then
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by neo4a,
13. Feb 2012
Der Interface-Ansatz kennt m.E. keine Hierarchien: Beide (TFuhrparkLeiter, TMotor) existieren unabhängig voneinander, sogar im richtigen Leben ;)
DI hat nur etwas mit Abhängigkeiten (Dependencies) zu tun. Damit also TFuhrparkleiter erfahren kann, ob aMotor Diesel will, muss er keinen Bauplan ala aMotor := TMotor.Create() haben, sondern er fragt das Etikett(Interface) aMotor : IMotor. Dort...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by neo4a,
13. Feb 2012
In Deinem Code lässt Du nur einen Motor zu. Lässt Du das AsSingleton wie vorgeschlagen weg, so gibt's mehrere Motoren.
Hinweis 1: Bei Spring brauchen die Interface-Deklarationen immer eine GUID, sonst gehen (intern) sämtliche Supports-Aufrufe nicht.
Hinweis 2: Spring verwaltet die Lifetime nur von AsSingleton-Interfaces. D.h. man benötigt bei AsTransient unbedingt eine Basisklasse, welches...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by neo4a,
13. Feb 2012
Ich benötige mehr Infos, eventuell konkrete Implementierungs-Details.
Ansonsten, wenn Du so initialisierst:
GlobalContainer.RegisterComponent<TMotor>.Implements<IMotor>;
dann ersetzt Du
var
aMotor : TMotor;
begin
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by neo4a,
13. Feb 2012
Dann lasse das .AsSingleton weg, dann bekommt jedes Auto seinen eigenen Motor (.AsTransient).
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by neo4a,
13. Feb 2012
Hier ein kleines Kochbuch:
Das Prinzip des Spring-DI-Containers ist - mit etwas Phantasie - vergleichbar mit den Abläufen bei der Automontage. Dort ist es ja eher unüblich, beim Montieren (Create) des Autos die Bestandteile (Motor, Blinker etc.) ebenfalls mit herzustellen: sie werden stattdessen aus dem Warenlager (DI-Container) so beigestellt, wie sie in der Produktion beim Create() des Autos...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by neo4a,
13. Feb 2012
Etwas weiter vorn gab's schon einmal ein Bild mit "Kuhzäunen". Und egal wie alt einer ist: Wer sich professionell mit IT-Themen beschäftigt, kennt die schnellen Zyklen und die kurzen Halbwertzeiten von IT-Expertenwissen. Ich bin überzeugt, dass es zwischen Qualität und Produktivität bei der Software-Entwicklung einen Zusammenhang gibt.
Einige Impulse kommen ja auch davon, dass viele Leute hier...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by neo4a,
12. Feb 2012
Dein Beitrag ist aus meiner Sicht leider nur rhetorisch gut, denn: Modularität, Clean-Code und die Anwendung von Design Pattern hat doch nichts mit Besessenheit und "Flexibilität bis zum Abwinken" zu tun. Vielmehr bilden sie einen abgesicherten Regelsatz, der nicht nur, aber vor allem in der Teamarbeit soetwas wie eine STVO für Programmierer darstellt.
Und Deine Schlussfolgerung, dass nur...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by neo4a,
12. Feb 2012
Ich habe mich nicht ganz präzise ausgedrückt, sorry. Was ich vor allem ansprechen wollte sind die GUI- und Persistenz- unterstützenden Komponenten, wo man halt dann die ganzen Properties im OI zusammenklickt.
Dass mein Beispiel nicht ganz passt, ist meinem Versuch geschuldet, den "Delphi-Weg" bei der Herangehensweise zu simulieren. Hätte ich vielleicht etwas besser machen können.
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by neo4a,
10. Feb 2012
Der (visuelle) Delphi-RAD-Ansatz, der den Einsatz mehrerer/vieler miteinander verknüpfter Komponenten bedeutet, steht einer vernünftigen, automatisierten Teststrategie entgegen.
Erzeuge ich dagegen die Komponenten aber bereits im Code, dann ist der Übergang zu DI-Containern sehr viel einfacher realisierbar. Damit ist auch die Ableitung eigener Komponenten inklusive Test viel leichter...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
Delphi
by neo4a,
2. Feb 2012
Ich beziehe mich einmal auf obiges Beispiel.
Spring ruft beim (internen) Instantiieren von TMyDatabase den Konstruktor ohne Parameter auf. Wenn das nicht geht, muss man bei GlobalContainer.RegisterComponent<TMyDatabase>.Implements<IDatabase>.AsSingletonPerThread noch Spring mitteilen, welcher Konstruktor verwendet werden soll. Hier kommt der DelegatedConstructor in's Spiel:
...