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