Какова наилучшая стратегия для внедрения зависимостей пользовательского ввода?

Есть два пути, по которым вы можете пойти, в зависимости от ваших потребностей.

1. Подключите пользовательский интерфейс напрямую к вашим конкретным классам

Это самый простой вариант, но во многих случаях вполне приемлемый. Хотя у вас может быть модель домена с множеством интерфейсов и использованием DI, пользовательский интерфейс представляет собой корень композиции графов объектов, и вы можете просто подключить здесь свой конкретный класс, включая требуемый параметр номера порта.

Положительным моментом является то, что этот подход прост и легок для понимания и реализации.

Недостатком является то, что вы получаете меньше гибкости. Вы не сможете произвольно заменить одну реализацию другой (но опять же, вам может не понадобиться эта гибкость).

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

2. Добавьте абстрактную фабрику

Другой вариант — добавить еще один уровень косвенности. Вместо того, чтобы ваш пользовательский интерфейс создавал класс напрямую, он мог бы использовать абстрактную фабрику для создания экземпляра.

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

public abstract class MyFactory
{
    public abstract IMyInterface Create(int portNumber);
}

Затем вы можете подключить контейнер DI к реализации этой фабрики, которая использует номер порта и передает его в качестве аргумента конструктора вашей реальной реализации. Другие фабричные реализации могут просто игнорировать этот параметр.

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

Недостатком является то, что он добавляет еще один уровень косвенности.

Большинство контейнеров IoC имеют ту или иную форму внедрения конструктора, которая позволяет вашему IoC container для передачи фиктивного COM-порта в ваш класс для модульного тестирования. Это кажется самым чистым решением.

Я бы не стал добавлять метод «Пуск» и т. д. Гораздо лучше (когда это возможно) всегда иметь ваши классы в допустимом состоянии, а переключение на конструктор без параметров с методом запуска оставляет ваш класс недействительным между этими вызовами. Делая это, чтобы включить тестирование, вы просто усложняете свой класс для тестирования (что должно сделать его лучше).