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