2010-03-23 8 views
6

Meine Motivation, meine Klassenkonstruktoren hier zu verketten, ist so, dass ich einen Standardkonstruktor für den Mainstream-Gebrauch durch meine Anwendung habe und eine Sekunde, die es mir erlaubt, einen Mock und einen Stub zu injizieren.Ist das eine gute oder schlechte Methode, Konstruktoren zu verwenden? (... um das Testen zu ermöglichen)

Es scheint nur ein bisschen hässlich 'neue' Dinge in der ": this (...)" Aufruf und kontraintuitiv Aufruf eines parametrisierten Konstruktors von einem Standard-Konstruktor, fragte ich mich, was andere Leute hier tun würden?

(FYI ->SystemWrapper)

using SystemWrapper; 

public class MyDirectoryWorker{ 

    // SystemWrapper interface allows for stub of sealed .Net class. 
    private IDirectoryInfoWrap dirInf; 

    private FileSystemWatcher watcher; 

    public MyDirectoryWorker() 
     : this(
     new DirectoryInfoWrap(new DirectoryInfo(MyDirPath)), 
     new FileSystemWatcher()) { } 


    public MyDirectoryWorker(IDirectoryInfoWrap dirInf, FileSystemWatcher watcher) 
    { 
     this.dirInf = dirInf; 
     if(!dirInf.Exists){ 
      dirInf.Create(); 
     } 

     this.watcher = watcher; 

     watcher.Path = dirInf.FullName; 

     watcher.NotifyFilter = NotifyFilters.FileName; 
     watcher.Created += new FileSystemEventHandler(watcher_Created); 
     watcher.Deleted += new FileSystemEventHandler(watcher_Deleted); 
     watcher.Renamed += new RenamedEventHandler(watcher_Renamed); 
     watcher.EnableRaisingEvents = true; 
    } 

    public static string MyDirPath{get{return Settings.Default.MyDefaultDirPath;}} 

    // etc... 
} 
+1

Es gab eine ganze Menge Diskussion darüber auf SO. Siehe beispielsweise http://stackoverflow.com/questions/300286/constructor-injection-and-default-overloads. Der allgemeine Konsens scheint zu sein, dass das Hinzufügen des Standardkonstruktors unnötigerweise verwirrend sein kann, obwohl einige argumentieren, dass es sich lohnt, wenn Ihre Bibliothek von Anrufern verwendet wird, die kein Abhängigkeitsinjektions-Framework verwenden. –

+0

Danke für den Link. In meinem Fall schreibe ich eine eigenständige Anwendung statt einer Bibliothek. Dependency-Injection-Frameworks sind eine weitere Stufe auf der kurvenreichen Lernleiter, von der ich jetzt aus bin, aber etwas, das ich untersuchen sollte. – Grokodile

Antwort

3

ein Standard-Konstruktor Einschließlich ist ein Code Geruch wie nun die Klasse auf die konkrete Umsetzung der IDirectoryInfoWrap gekoppelt ist. Um Ihr Leben zu erleichtern, verwenden Sie einen IOC-Container außerhalb der Klasse, um abhängig davon, ob Sie Testcode oder die Mainstream-Anwendung ausführen, unterschiedliche Abhängigkeiten zu injizieren.

+1

http://martinfowler.com/bliki/InversionOfControl.html zu meiner Leseliste hinzugefügt, danke. – Grokodile

0

, der ziemlich genau ist, wie ich es tun.

class MyUnitTestableClass 
{ 
    public MyUnitTestableClass(IMockable foo) 
    { 
     // do stuff 
    } 

    public MyUnitTestableClass() 
     : this(new DefaultImplementation()) 
    { 
    } 
} 
Verwandte Themen