Різниця між "Інверсія управління", "Інверсія залежності" та "Роз'єднання"


80

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

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

Роз’єднання розповідає про те саме і про те, як цього досягти. Але тоді у нас є IoC-контейнери, які ще більше заплутують ситуацію. Чому їх радше не називають контейнерами для інверсії залежностей або навіть краще контейнерами для ін'єкцій залежності , оскільки вони служать для взаємодії незалежних компонентів під час виконання?

Тоді ми маємо інверсію контролю . В основному це те саме, що і інверсія залежностей, чи не так? Чому існує три терміни, що описують одне і те ж? Або я сліпий?

  1. У чому різниця між трьома?
  2. Що IoC повинен робити в контейнерах IoC?

@ Антон Гоголєв: Роз'єднання пишеться зайвим "о": en.wikipedia.org/wiki/Decoupling#Software_Development
Роберт Коритник

Відповіді:


79

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

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

Інверсія управління - це принцип проектування, що використовується бібліотеками фреймворку, які дозволяють фреймворку відновити певний контроль із програми. Тобто фреймворк вікна може повернутися до коду програми, коли відбуваються певні події інтерфейсу користувача. Мартін Фаулер використовує термін Голлівудський принцип, як у " Не дзвоніть нам, ми зателефонуємо вам . Роз'єднання є важливою частиною інверсії контролю.

Але яке відношення має контейнер IoC до інверсії управління? Процитувавши Мартіна Фаулера :

Інверсія контролю - занадто загальний термін, і тому люди вважають це заплутаним. В результаті багато обговорень з різними прихильниками IoC ми зупинились на назві Dependency Injection.

(Зверніть увагу, що Мартін Фаулер говорить про введення залежності , а не про інверсію залежності .)

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

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


Я погоджуюсь, хоча я б не використовував термін IoC-контейнер, оскільки він, як ви кажете, насправді не правильний. Я вважаю, що неважливо дотримуватися (неправильної) популярної схеми іменування тут, оскільки кожен, хто розуміє принцип DI-контейнерів, повинен мати можливість зрозуміти правильне іменування.
Андрій Щекін,

49

Інжекція залежності досягає роз'єднання за допомогою інверсії управління .


4
це думка Інверсія контролю чи це інверсія залежності ? Я б сказав, що це останнє.
Robert Koritnik,

1
-1 це насправді поєднує термін "введення залежності" з "інверсією контролю". Ін’єкція залежності - це самостійний метод розв’язки.
Маурісіо Шеффер

2
@Mauricio: Я не думаю , що Dependency Injection є Розв'язка або розчеплення техніки взагалі. DI забезпечує засоби для зчеплення нерозв’язаних компонентів. Не навпаки.
Robert Koritnik,

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

jeez досить сказав :( це було непогано писати Борисе. Існує занадто багато способів зробити все. Головне, щоб існувала довіра та повага в команді. З чистої точки зору не було б ніякої користі від принципів проектування програмного забезпечення і книги про них, якщо колективна робота була оптимальною і переконання у власній роботі існувало.
Майк Соча III

26

Я знаходжу таке пояснення від DIP у статті Wild на martinfowler.com прямо для розуміння (тут DI = ін'єкція залежності, DIP = принцип інверсії залежності, IoC = інверсія контролю):

DI - це те, як один об’єкт набуває залежності. Коли залежність надається зовні, тоді система використовує DI. IoC - це те, хто ініціює дзвінок. Якщо ваш код ініціює виклик, це не IoC, якщо контейнер / система / бібліотека знову викликає код, який ви йому надали, це IoC.

DIP, навпаки, стосується рівня абстракції в повідомленнях, надісланих з вашого коду тому, кого він викликає. (...) DI - про проводку, IoC - про напрямок, а DIP - про форму [об’єкта, від якого залежить код].


5
"DI - про проводку, IoC - про напрямок, а DIP - про форму [об’єкта, від якого залежить код]." це був гарний вирок;)
Амір Зіараті

1
Я вважаю форму слова заплутаною в останньому реченні. Здається, це не додає нічого, крім того, що вже було сказано: DIP - це абстракція. Я б сказав, що IoC - це про кого , DIP - про що , а DI - про те, як . Хто контролює залежність? Що абстрагується від залежності? Як доставляється залежність?
jaco0646

2

Інверсія залежності: Залежить від абстракцій, а не від конкрементів.

Інверсія контролю: Main vs Abstraction, і те, як Main є клеєм систем.

DIP та IoC

Ось кілька хороших постів, які говорять про це:

https://coderstower.com/2019/03/26/dependency-inversion-why-you-shouldnt-avoid-it/

https://coderstower.com/2019/04/02/main-and-abstraction-the-decoupled-peers/

https://coderstower.com/2019/04/09/inversion-of-control-putting-all-together/

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.