Слишком много фабрик в результате написания тестируемого кода

Question

Я пытаюсь написать код, который можно легко протестировать. Это заставляет меня избегать прямого вызова нового Class1 (). Вместо этого я обычно создаю интерфейс, простую фабрику с одним методом GetObject (), который возвращает этот интерфейс.

Работает нормально. Проблема, которую я нахожу, заключается в слишком большом количестве фабрик, которые в основном не имеют ничего, кроме вызова нового Class1 () (или любого другого класса / интерфейса, за который они отвечают). Я не думаю, что платить за наличие тестируемого кода стоит дорого, но все же ... Кто-нибудь использует лучший подход и все же достигает цели, заключающейся в том, чтобы внедрить другую реализацию Class1 во время тестирования?

Я знаю, что мог бы представить реализацию Class1 как свойство и использовать значение по умолчанию во время выполнения, но это означало бы, что я ограничен одним экземпляром, хотя во многих случаях я хочу создавать новый экземпляр каждый раз, когда мне нужен этот Class1.

Edit:
Я использую IoC, и это действительно помогает. Тем не менее, я обычно получаю фабрику как зависимость в конфигурации IoC. Мои методы GetObject обычно вызывают что-то вроде IoC.Resolve. Я предпочитаю изолировать зависимость IoC на фабриках, а не напрямую в классах доменов, которые содержат бизнес-логику.

Answer 1

Есть много структур, которые помогают в достижении этого.Техника называется инверсия управления .Примеры в мире .NET:

• Spring.NET
• StructureMap
• Замок Виндзор

Общей точкой всех этих платформ является способность выводить привязки между компонентами (классами) в конфигурацию, которая выражается либо в виде файла конфигурации (то есть в XML), либо в виде «начальной загрузки»Код.Они могут автоматически внедрять зависимости в экземпляры и решать проблему инстанцирования и конфигурирования классов.По сути, вы можете оставить эту задачу на контейнере IoC и выйти из создания пользовательских классов фабрики.

Соответствующие ресурсы в SO помечены ioc-container .

Мартин Фаулер имеет статья , описывающая IoC и методы реализации, такие как внедрение зависимостей и указатель службы.

Answer 2

Было бы проще, если бы я знал, на каком языке вы говорите, но большинство языков имеют какое-то понятие родового или другого.Таким образом, вы можете сделать свой интерфейс фабрики универсальным:

Java-версия:

public interface Factory<K>{
    K create();
}

Библиотеки Guava имеют интерфейс Supplier<K>именно для этой цели.Я бы предложил использовать такой квази-стандарт (я думаю, что нечто подобное будет доступно и для других языков).