DI / IoC контейнери та заводи: Де я можу налаштувати свою програму і чому?

Я намагаюся розібратися, коли використовувати реєстр DIC / IoC для налаштування мого програмного забезпечення та коли використовувати фабрики, а також міркування щодо будь-якого підходу.

Я використовую StructureMap як мій контейнер DI (DIC), який легко налаштувати за допомогою реєстрів. У DIC практично всі зареєстровані об'єкти є статичними в тому сенсі, що мені не потрібно змінювати / обмінювати будь-яку реалізацію / екземпляр під час виконання, коли DIC налаштований і вони налаштовані в DIC як одиночні кнопки. Однак, оскільки моє програмне забезпечення (SW) працює на різних пристроях, мені потрібно вибрати реєстр, що залежить від пристрою, залежно від пристрою, на якому працює мій SW, щоб відповідно налаштувати обладнання.

Оскільки побудова деяких моїх об'єктів вимагає читання у файлах конфігурації, я використовую фабрики для повернення цих екземплярів у DIC, щоб відокремити зчитування конфігурації від створення об’єкта. Я зареєстрував заводські геттери в DIC для відповідних типів плагінів.

Тепер у мене є тип плагіна IMotorз конкретними типами Motor1і Motor2, які повинні бути оброблені на заводі. Зараз я вирішую, як налаштувати свій пристрій, є два способи:

1. Я передаю інформацію про пристрій, на якому працює SW, MotorFactoryі він повертає правильний двигун, Motor1або Motor2. У цьому випадку логіка прийняття рішення знаходиться всередині Заводу.
2. Я налаштовую DIC відповідно до пристрою, на якому він працює, і створюю дві фабрики Motor1Factoryі Motor2Factoryтам, де одна створює Motor1та іншу Motor2. У цьому випадку я мав би відрізняти записи реєстру для IMotorконкретних реєстрів пристроїв, які використовують Motor1Factoryабо Motor2Factory.

Тепер моє запитання: який із цих двох методів є кращим і чому? Мені здається, перший випадок не є прямолінійним і перекрученим, оскільки я поширюю логіку, яка визначає, який тип інстанціювати в кодовій базі. Тоді як у другому випадку я фактично множу кількість заводів у своєму коді, оскільки мені знадобиться фабрика для (майже) кожного конкретного типу. Мені це стає ще більш заплутаним, коли до суміші додаються абстрактні фабрики.

Отже знову: Коли я повинен використовувати той чи інший метод? І що ще важливіше: які хороші показники для вирішення, яким шляхом йти?

Якщо ви використовуєте обидва, я піду для чогось простого:

• DI / IoC: для кожної конфігурації, яка не змінюється під час виконання.
• Фабрика: для створення примірників об'єктів під час виконання, що залежить від вхідних параметрів часу виконання. Екземпляри фабрики вводять контейнер DI.

Абстрактні фабрики використовуються, коли у вас є об'єкти, пов’язані через ієрархію, яка повинна змінюватися разом. Я цього не бачу тут.

Що я бачу, це те, що вам цікаво, чи фабрика повинна вибрати двигун, чи DIC повинен вибрати завод, який виробляє певний двигун.

Це важко вибрати саме тому, що завод і DIC роблять дуже подібні речі. Різниця полягає в тому, що фабрика зосереджена на певному питанні, а DIC є більш загальним.

Зводиться до цього питання: чи є у вас потреба в коді, який є специфічним для цього питання, який буде жити на заводі? Або це більш загальне, як читання деталей конфігурації з файлу?

Майте на увазі, що хоча ви можете вибирати лише сьогодні Motor1і Motor2сьогодні, завтра це може бути Motor3. Віддавайте перевагу дизайну, який було б Motor3легко додати.

Я б розділив логіку "який двигун використовувати" у спеціальній фабриці під назвою Builder (шаблоном) і використаю IOC-контейнер для обох двигунів як деталі реалізації будівельника.

Як правило:

• вам потрібна фабрика (або будівельник), якщо вам доведеться створити багато динамічних об'єктів класу / інтерфейсу. (тобто для кожного виробленого автомобіля ви повинні створити один новий мотор)
• якщо вам потрібен лише один статичний екземпляр класу, ioc / di може виконати роботу за вас (тобто вам потрібен лише один статичний екземпляр служби платежів і один статичний екземпляр MotorBuilderService)