Яку користь купу автомобільних частин, що сидять на гоночній трасі, хто робить?
Якщо у вашому класі автомобілів є автозапчастини, це так само корисно, як і вологий мішок з деталями.
Використання
Як водій, я хочу контролювати те, що я хочу. Це відповідає, коли я прошу швидкості. Це ручки, як його на рейках. Це може зупинитися на копійці.
Що я хочу - це клас автомобілів, який можна використовувати. Що я можу сказати робити речі, не замислюючись про те, як працює карбюратор. Я просто думаю про педаль газу. Те, як вони пов’язані, не хвилюється. Це абстракція.
Ін'єкційна залежність
Ін'єкція залежності не має нічого спільного з цим. Коли я за кермом автомобіля, я не замислююся про те, як він був побудований. Поки це працює, мені не байдуже, як вони це складають.
Ні, DI - це те, що дозволяє моєму піт-екіпажу швидко міняти свої шини на кращі, коли на доріжці починає дощ. Приємно бути в змозі зробити це без того, щоб стрибати у зовсім інший автомобіль.
DI дійсно стосується принципу: Окреме використання від будівництва.
Автомобіль, який може встановити нові шини за швидкість 90 миль на годину, може здатися здоровим, але я не думаю, що він не виграє жодних перегонів, якщо шина встановить на ньому контрацепцію.
DI - це встановлення деталей таким чином, щоб ваш екіпаж ями дістався до них. Якщо ви користуєтесь newтам же, ви програмуєте поведінку, це так, ніби ви зварюєте карбюратор на місце. Впевнені, що ацетиленовий факел може його зняти, але, будь ласка, спочатку подумайте про використання гайок і болтів.
Ось що таке DI. Впевнений, що це не так просто, як newпідготувати щось, як тільки ти зрозумієш, що цього хочеш. Натомість вам потрібно написати окремий код, який знає, як побудувати свій автомобіль. Але це впевнено полегшує змінити речі згодом. А це означає, що вам не доведеться перетягувати завод збору автомобілів навколо колії.
Будівництво
Щось десь має знати, чи є шини Goodyear. Куди тоді поставити код будівництва автомобіля? Якщо не машина, то піт-екіпаж? Ні. Доріжка? Ні. Усі мають код поведінки. Код, який повинен виконувати під час гонки. Побудова автомобіля повинна відбуватися перед гонкою в місці, усуненому від коду поведінки. Марк Сейманс назвав це місце складом корінь . Більшість людей називає це головним.
Це проста модель. В основному, побудуйте графік об'єкта, а потім викликайте один метод поведінки на одному об'єкті в об'єктному графіку. Це воно. Це ТІЛЬКИ будівництво місця та поведінка повинні бути разом.
Це не означає, що конструкція має бути купою процедурного кодексу, викладеного послідовно в основному. Ви можете вільно користуватися будь-яким інструментом на мові для будівництва. Просто не змішуйте це з поведінкою.
Робити це мовою, а не використовувати якусь рамку DI чи контейнер IoC, називається чистим DI . Це працює дуже добре. Має давно. Ми звикли просто називати це посиланням проходженням .
Інструменти DI
Що вам купує інструмент DI - це деталі побудови, переміщені на іншу мову (xml, json, будь-яку іншу), яка примушує розмежувати конструкцію та поведінку. Якщо ви не довіряєте своїм колегам-програмістам не користуватися, newколи вони не повинні, це може бути привабливим.
Зворотний результат полягає в тому, що детально про інструмент DI розповсюджуватись по всій кодовій базі непросто. Іноді заражає кодову базу власними анотаціями. Наведені ними приклади, безумовно, заохочують це. Інструмент, як правило, рухається в мовному просторі, поки ви не зможете просто рекламувати завдання як завдання програмування Java, але як завдання програмування Java / Spring.
Принципи дизайну
Протягом століть я програмував Автомобільні класи, тому що для мене було очевидно, що мені потрібен клас "Автомобіль", якщо я програмую логіку автомобіля. Але з DI це для мене не так очевидно. Все ще цікаво, чи це ідіоматичне для DI не створювати клас автомобілів, якщо я не маю для нього визначеної ролі?
Я думаю, ви дізнаєтесь про абстракцію та зміните те, як вирішите, що клас потрібен. Це добре. Але справа не в DI. DI не допоможе вам вирішити, чи потрібен вам автомобільний клас. DI допомагає вам уникнути того, щоб автомобіль не знав, а для цього дбали, якщо шини - це шини Goodyear. DI допомагає вам не відслідковувати, чи автомобілі зроблені в Японії.
Одне з найбільш фундаментальних питань в розробці програмного забезпечення - "що знає про що?" Це головне, що вам показує діаграма UML. Коли ви створюєте щось нове, до якого ви досягаєте минулого, це інтерфейс до конкретної речі, до якої ви зараз прив'язані. Автомобіль тепер повинен знати, що шини - це Goodyear. Що ні за що не підходить, якщо Мішелін хоче спонсорувати вас.
Уникати цього потрібно називати за принципом інверсії залежності . Формально модуль високого рівня (як автомобільний клас) не повинен безпосередньо залежати від модулів низького рівня (наприклад, клас GoodyearTire). Це має залежати від абстракції (як інтерфейс шини).
Спосіб уникнути цього називається Інверсія управління . Тут акцент робиться на зміні потоку управління. Чи шини переміщують машину чи автомобіль переміщує шини? Думаючи про це правильний спосіб дозволяє нам не статично з'єднувати автомобіль та шини разом. DI - це один із певних способів слідувати Інверсії управління.
Ніщо з цього не говорить про те, чи потрібен вам автомобільний клас. Якщо ви програмуєте "логіку автомобіля", це добре, якщо є одне місце, щоб зберегти його, а не розкидати його кудись. Тільки не обманюйтеся, що логіка побудови автомобіля така ж, як логіка поведінки автомобіля, тому все має жити там же. Але якщо у вас немає визначеного рулону для машини, то вам також не потрібен. Перегони мотоциклів навколо доріжки, якщо вам подобається.
Я маю на увазі, чи добре мати SteeringWheel для водіння, BoltsAndNuts на колесах для піт-екіпажу та всілякі інші смішні інтерфейси, не маючи примірника, який представляє автомобіль у цілому?
DI чи ні DI, це добре мати екземпляр, який представляє автомобіль в цілому, але цей екземпляр - це не те, про що я хочу знати безпосередньо, якщо мені цього не потрібно. Дайте мені автомобільну абстракцію, щоб мені не було байдуже, чи працює вона на газі, дизелі чи електриці, коли я ним користуюся. Це лише те, про що я повинен дбати, коли будую його чи підтримую. Приємно, якщо код, який використовує автомобіль, не повинен знати або дбати, як він працює. "Я не знаю. Я не хочу знати".