Schönes Thema mit kontroversen Meinungen. Zur Ehrenrettung der "Hab-Ich-Schon-Immer-So-Gemacht"-Fraktion sollte vielleicht nicht unerwähnt bleiben, dass viele Lösungsansätze in Delphi erst seit relativ kurzer Zeit zur Verfügung stehen.
Meine Motivation, den Delphi-
RAD-Ansatz (teilweise) zu verlassen, kommt aus der Einsicht, durchgängig testbaren Code zu entwickeln. M. Hevery (Chef-Tester von Google) hat die Vorteile von Data-Binding so zusammengefasst:
- MVC leidet naturgemäß an zirkulären Referenzen, die Probleme erzeugen und
Unit-Testing sehr erschweren.
- Data-Binding kehrt den normalen Ablauf der Abhängigkeiten um, erlaubt es zirkuläre Referenzen zu vermeiden und weniger gekoppelte Systeme zu erzeugen.
- Data-Binding eliminiert viel Boiler-Plate-Code, der die Daten zwischen Model und View hin und her transportiert und macht unseren Code leichter lesbar und verständlicher.
Dieses Mantra hat er
hier 2010 veröffentlicht und 1 Jahr später gibt es nun Delphi-Ansätze (aber nur für die letzten Versionen), wie man das Data-Binding nutzen kann.
N. Hodge (ehem. Delphi-Manager) hat in Zusammenhang mit Dependency-Injection
hier gefordert:
Regel 1: Codiere immer mit/gegen Interfaces
Regel 2: Halte den Constructor einfach
Mit einem geeigneten Framework
wie Emballo ("nimmt Interfaces den Schrecken") oder Stevies DSharp schreibt man nun Programme, die sich auf einmal "richtig" anfühlen. Auch wenn man es zurzeit noch nicht nutzt: Tests, Mockups,
GUI-Austausch, verschiedene
OS - das alles ist auf einmal greifbar nahe.
(Nicht nur HP's letzter Haken zeigt: Die IT-Zukunft wird durch die Software bestimmt. Und mir ist dabei wichtig, bei all den Wechseln gelassen bleiben zu können und bei Ziel-Plattform und -
OS die zu bedienen, für die sich letztlich meine Kunden entscheiden.)