Моя мотивация для объединения в цепочку моих конструкторов класса вот - то, так, чтобы у меня был конструктор по умолчанию для основного использования моим приложением и секунда, которая позволяет мне вводить насмешку и тупик.
Это просто кажется немного ужасными 'новыми вещами '-луга в ": это (...)" звонит и парадоксальный вызов параметрического конструктора из конструктора по умолчанию, я задался вопросом, что другие люди сделают здесь?
(К вашему сведению-> 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...
}
Включение конструктора по умолчанию - это запах кода, поскольку теперь класс связан с конкретной реализацией IDirectoryInfoWrap. Чтобы упростить себе жизнь, используйте контейнер IOC, внешний по отношению к классу, для внедрения различных зависимостей в зависимости от того, запускаете ли вы тестовый код или основное приложение.
Это практически то, как я это делаю.
class MyUnitTestableClass
{
public MyUnitTestableClass(IMockable foo)
{
// do stuff
}
public MyUnitTestableClass()
: this(new DefaultImplementation())
{
}
}