TDD означает Test- Driven Design, и можно сделать вывод, что конструктор не может быть внутренним «по замыслу», если вы не можете его проверить.
Подумайте, почему это внутреннее. Это расскажет вам, как решить проблему. Вы не должны делать конструктор общедоступным только для того, чтобы иметь возможность его протестировать, но вы должны рассмотреть проект, который облегчает создание новых экземпляров.
Зачастую конструкторы делаются внутренними для защиты инвариантов, но вы также можете достичь той же цели с открытым конструктором, который принимает требуемый ввод в качестве параметров конструктора.
public class MyClass
{
private readonly string requiredString;
public MyClass(string requiredString)
{
if (requiredString == null)
{
throw new ArgumentNullException("requiredString");
}
this.requiredString = requiredString;
}
}
Обратите внимание, как комбинация пункта Guard и ключевого слова readonly защищает инвариант класса. Часто это хорошая альтернатива внутренним конструкторам.
Другая причина наличия внутренних конструкторов заключается в том, что у вас есть Фабричный метод, который может вернуть полиморфный объект, но еще раз подумайте, не будет ли проблем разоблачить конструктор, если он не означает компромиссные инварианты.
Красота TDD заключается в том, что она заставляет нас внимательно смотреть на любое дизайнерское решение и иметь возможность реально оправдать каждого из них. Рассмотрите обоснование создания конструктора внутренним, а затем модифицируйте API, чтобы тип легко создавался.