여기에 내 클래스 생성자를 체인에 대한 동기는 그래서 내 응용 프로그램에 의해 주류 사용을위한 기본 생성자 및 모의 및 스텁을 주입 수있는 두 번째입니다.생성자 체인을 사용하는 것이 좋든 나쁘지 않습니까? (... 허용 테스트 ...)
기본 생성자에서 매개 변수화 된 생성자를 호출하는 "this (...)"호출 및 반 직관적 인 호출에서 추악한 '새로운'것처럼 보입니다. 나는 다른 사람들이 여기서 무엇을 할 것인지 궁금해 했습니까?
(참고 ->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...
}
이에 대한 논의가 상당 부분있었습니다. 예를 들어 http://stackoverflow.com/questions/300286/constructor-injection-and-default-overloads를 참조하십시오. 일반적인 컨센서스는 기본 생성자를 추가하는 것이 불필요하게 혼란 스러울 수 있지만, 일부는 의존성 삽입 프레임 워크를 사용하지 않는 호출자가 라이브러리를 사용할 때 가치가 있다고 주장합니다. –
링크를 제공해 주셔서 감사합니다. 필자는 필자가 라이브러리가 아닌 독립형 애플리케이션을 작성하고있다. 의존성 주입 프레임 워크는 내가 현재 있어야 할 곳에서부터 곡선을 그리는 학습용 사다리의 또 다른 위업이지만 조사해야 할 부분입니다. – Grokodile