ClassFactory ähnlich wie Spring Framework, Hilfe gesucht!

[Stevie]

Zitat von Mavarik:

Es hat sich mir auch nicht erschlossen, warum ich die Implementierung des Interfaces nicht in der gleichen Unit machen soll.

Das erschließt sich meist erst, wenn man eine größere bzw "richtige" Anwendung hat. In dem Fall ein Interface, eine Klasse mag es erstmal unnötige Arbeit sein, das in eigene Unit zu packen, aber wenn diese dann von anderen Teilen benutzt merkt man, dass man bei einer Trennung dort tatsächlich nur eine Abhängigkeit auf die Abstraktion (Interface) hat und sich auch nicht von hinten rum, die Implementierung rein holt (weil sie in derselben Unit wie das Interface ist). Wenn man mehrere Implementierungen für ein Interface hat, fällt es direkt auf. Und wenn man dann einen Unittest für Klasse A schreibt, die Interface B benutzt, was man nur ausmocken muss, aber trotzdem Klasse B im Test drin ist, auch.

Man merkt sowas immer schnell, wenn man mal kurz eine kleine Testapplikation schreibt, welche ein TToaster testen will. Und plötzlich wundert man sich, dass in die Anwendung auch TStadtwerke , TUmspannwerk , TKraftwerk und TBraunkohletagebau einkompiliert werden, nur weil man den TToaster an den Strom anschließen kann.

Ich stimme dir aber zu, wenn man das so praktiziert, kann das zu langen uses Klauseln kommen, dahingehend hat man es in Java oder C# einfacher mit richtigem Namespacing (so nach dem Motto uses MyLib.*; statt uses MyLib.Foo, MyLib.Bar, MyLib.MoreStuff, ...; ).

[Uwe Raabe]

Zitat von Stevie:

Ich stimme dir aber zu, wenn man das so praktiziert, kann das zu langen uses Klauseln kommen, dahingehend hat man es in Java oder C# einfacher mit richtigem Namespacing (so nach dem Motto uses MyLib.*; statt uses MyLib.Foo, MyLib.Bar, MyLib.MoreStuff, ...; ).

Dieses Feature birgt aber wiederum andere Gefahren: Damit würden ja alle Units dieses NameSpace (MyLib) eingebunden die im Suchpfad gefunden werden. Das wäre mit den aktuellen Units von Delphi XE5 schon mal nicht praktikabel, da dort z.B. plattformabhängige Units gleichnamige Methoden deklarieren (bei FMX z.B. FMX.Controls.<Android|iOS|Mac|Win>). Bei einem NameSpace FireDAC.* hätte man plötzlich alle verfügbaren Datenbanktreiber mit eingebunden, was in den seltensten Fällen wirklich erwünscht ist. Für selbstgestrickte Units kann man da sicher Vorkehrungen treffen, aber dann müssen die NameSpaces und Unitnamen auch gut überlegt sein.

[Stevie]

Zitat von Uwe Raabe:

Dieses Feature birgt aber wiederum andere Gefahren: Damit würden ja alle Units dieses NameSpace (MyLib) eingebunden die im Suchpfad gefunden werden. Das wäre mit den aktuellen Units von Delphi XE5 schon mal nicht praktikabel, da dort z.B. plattformabhängige Units gleichnamige Methoden deklarieren (bei FMX z.B. FMX.Controls.<Android|iOS|Mac|Win>). Bei einem NameSpace FireDAC.* hätte man plötzlich alle verfügbaren Datenbanktreiber mit eingebunden, was in den seltensten Fällen wirklich erwünscht ist. Für selbstgestrickte Units kann man da sicher Vorkehrungen treffen, aber dann müssen die NameSpaces und Unitnamen auch gut überlegt sein.

Ich wär ja schon glücklich, wenn man generische Typen redeklarieren könnte, dann könnte man sich so pseudo Namespace Units bauen, wo man Dinge aus anderen Units zusammenführen kann.