Введення залежності через конструктори чи властивості властивостей?

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

Це, мабуть, не є моделлю з існуючим тут кодом, тому я хочу дізнатися, що таке загальний консенсус, плюси та мінуси конструкторів та властивостей. Чи краще використовувати налаштування властивостей?

Ну, це залежить :-).

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

Якщо клас може працювати без залежності, сеттер добре.

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

Крім того, щоб уникнути необхідності змінювати використання старого конструктора, просто застосуйте ланцюги конструкторів як тимчасовий міст між старим та новим конструктором.

public class ClassExample
{
    public ClassExample(IDependencyOne dependencyOne, IDependencyTwo dependencyTwo)
        : this (dependnecyOne, dependencyTwo, new DependnecyThreeConcreteImpl())
    { }

    public ClassExample(IDependencyOne dependencyOne, IDependencyTwo dependencyTwo, IDependencyThree dependencyThree)
    {
        // Set the properties here.
    }
}

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

Звичайно, надягаючи на конструктор - це означає, що ви можете перевірити всі відразу. Якщо ви присвоюєте речі лише полям, доступним для читання, ви маєте певні гарантії щодо залежності вашого об'єкта від часу побудови.

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

Якщо у вас велика кількість необов'язкових залежностей (що вже є запахом), можливо, введення сетеру - це шлях. Інжекція конструктора краще виявляє ваші залежності.

Загальний переважний підхід полягає в тому, щоб якомога більше використовувати інжектор конструктора.

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

Постарайтеся мати лише одного конструктора, це спрощує дизайн і уникає неоднозначності (якщо не для людей, то для контейнера DI).

Ви можете використовувати введення властивостей, коли у вас є те, що Марк Семанн називає локальним за замовчуванням у своїй книзі "Введення залежності в .NET": залежність не є обов'язковою, оскільки ви можете забезпечити точну робочу реалізацію, але хочете дозволити абоненту вказати інший, якщо потрібні.

(Раніше відповідь нижче)

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

Ін'єкція сетера приємна, якщо ін'єкція є необов'язковою або якщо ви хочете змінити її на півдорозі. Я, як правило, не люблю сетерів, але це питання смаку.

Це багато в чому питання особистого смаку. Особисто я віддаю перевагу ін'єкції сетера, тому що я вважаю, що це дає вам більше гнучкості в тому, що ви можете підміняти реалізацію під час виконання. Крім того, на мою думку, конструктори з великою кількістю аргументів не є чіткими, і аргументи, надані в конструкторі, повинні обмежуватися необов'язковими аргументами.

Поки інтерфейс класів (API) зрозумілий у тому, що йому потрібно для виконання свого завдання, ви добре.

Особисто я віддаю перевагу "шаблону" витягування та заміщення над введенням залежностей у конструктор, значною мірою з причини, викладеної у вашому запитанні. Ви можете встановити властивості як, virtualа потім змінити реалізацію у похідному тестовому класі.

Я віддаю перевагу конструкторському введенню, оскільки це допомагає "нав'язати" вимоги до залежності класу. Якщо це в c'tor, споживач повинен встановити об'єкти , щоб отримати додаток для компіляції. Якщо ви використовуєте ін'єкцію сетера, вони можуть не знати, що вони мають проблеми до часу запуску - і залежно від об'єкта, це може бути пізно у часі виконання.

Я все ще час від часу використовую ін'єкцію сетера, коли ін'єктованому об'єкту, можливо, потрібна сама робота, як ініціалізація.

Я вважаю за краще введення конструктора, тому що це здається найбільш логічним. Начебто сказати, що мій клас вимагає, щоб ці залежності виконали свою роботу. Якщо його необов'язкова залежність, то властивості здаються розумними.

Я також використовую ін'єкцію властивостей для встановлення речей, на яких контейнер не має посилань на такі, як ASP.NET View на презентаторі, створеному за допомогою контейнера.

Я не думаю, що це порушує інкапсуляцію. Внутрішня робота повинна залишатися внутрішньою, а залежності стосуються іншого.

Один з варіантів, який, можливо, варто розглянути - складання складних множинних залежностей з простих одиничних залежностей. Тобто визначте додаткові класи для складових залежностей. Це полегшує введення конструкції WRT-конструктора - менша кількість параметрів на виклик, зберігаючи при цьому необхідні параметри, необхідні для забезпечення всіх потреб.

Звичайно, це має сенс, якщо існує якесь логічне групування залежностей, тому сполука є більш ніж довільною сукупністю, і це має найбільш сенс, якщо є кілька залежних для однієї складової залежності - але блок параметрів "шаблон" має довгий час, і більшість тих, кого я бачив, були досить довільними.

Особисто, однак, я більше прихильник використання методів / властивостей властивостей для визначення залежностей, параметрів тощо. Імена викликів допомагають описати, що відбувається. Хороша ідея надати приклад фрагментів цього-як-як-встановити-це-вгору і переконатися, що залежний клас робить достатньо перевірок помилок. Для налаштування ви можете використовувати модель кінцевого стану.

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

Використання необов'язкових параметрів може бути виконано лише в рамках, що їх підтримують, наприклад .NET 4 (як для C #, так і для VB.NET, хоча VB.NET завжди їх мав). Звичайно, ви можете домогтися подібної функціональності, просто скориставшись властивістю, яке може бути перепризначене споживачем вашого класу, але ви не отримаєте переваги незмінності, наданої, якщо об'єкт приватного інтерфейсу присвоєний параметру конструктора.

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

Це стара публікація, але якщо вона потрібна в майбутньому, можливо, це матиме користь:

https://github.com/omegamit6zeichen/prinject

У мене була подібна ідея і я придумав цю рамку. Це, мабуть, далеко не повне, але це ідея рамки, орієнтованої на введення властивостей

Це залежить від того, як ви хочете реалізувати. Я вважаю за краще інжектор конструктора там, де я відчуваю, що значення, що надходять до реалізації, часто не змінюються. Напр.: Якщо стратегія компанії йде з сервером Oracle, я налаштую свої значення джерела датчиків для підключення бобів через інжектор конструктора. В іншому випадку, якщо моя програма є продуктом і, швидше за все, вона зможе підключитися до будь-якого db замовника, я би реалізував таку конфігурацію db та впровадження декількох брендів через інжектор сетерів. Я щойно взяв приклад, але є кращі способи реалізації сценаріїв, про які я згадував вище.

Інжекція конструктора явно виявляє залежності, роблячи код більш читабельним і менш схильним до незроблених помилок під час виконання, якщо аргументи перевіряються в конструкторі, але це дійсно зводиться до особистої думки, і чим більше ви використовуєте DI, тим більше ви будете як правило, гойдаються вперед або вперед так чи інакше залежно від проекту. У мене особисто проблеми з кодом пахнуть конструкторами з довгим переліком аргументів, і я вважаю, що споживач об'єкта повинен знати залежності, щоб використовувати об'єкт так чи інакше, тому це робить причиною використання введення властивостей. Мені не подобається неявний характер введення властивостей, але я вважаю його більш елегантним, в результаті чого виходить більш чистий код. Але з іншого боку, впорскування конструктора все ж пропонує більш високий ступінь інкапсуляції,

Вибирайте ін'єкцію конструктором або майном розумно, виходячи з конкретного сценарію. І не відчувайте, що вам доведеться використовувати DI просто тому, що це здається необхідним, і це запобіжить поганий дизайн і запахи коду. Іноді не варто докладати зусиль для використання шаблону, якщо зусилля та складність переважають над користю. Не ускладнювати.