Запитання з тегом «inversion-of-control»

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

4
Різниця між впорскуванням залежності (DI) та інверсією управління (IOC)
Я бачив багато посилань на залежність впорскування (DI) та інверсії контролю (МОК), але я не знаю, чи є різниця між ними чи ні. Я хотів би почати використовувати одне чи обидва, але я трохи розгублений у тому, чим вони відрізняються.

7
Чому саме так називається інверсія управління?
Слова invertабо controlвзагалі не використовуються для визначення інверсії управління у визначених мною означеннях. Визначення Вікіпедія інверсія управління (IoC) - це метод програмування, виражений тут через об'єктно-орієнтоване програмування, в якому зв'язок об'єктів пов'язаний під час виконання об'єктом асемблера і, як правило, не відомий під час компіляції за допомогою статичного аналізу. ~ …

4
Що таке інверсія управління, і коли я повинен її використовувати?
Я розробляю нову систему і хочу знати, що таке інверсія управління (МОК), і що ще важливіше, коли її використовувати. Чи потрібно його реалізовувати за допомогою інтерфейсів чи це можна зробити з класами?

7
Принцип єдиної відповідальності - як я можу уникнути фрагментації коду?
Я працюю над командою, де керівник команди є щирим прихильником принципів розвитку SOLID. Однак йому не вистачає великого досвіду виведення складного програмного забезпечення з дверей. У нас є ситуація, коли він застосував SRP до того, що вже було досить складною базою коду, яка тепер стала дуже сильно фрагментованою і важкою …

5
Контейнери МОК порушують принципи ООП
Яке призначення контейнерів МОК? Сукупні причини цього можуть бути спрощені до наступних: При використанні принципів розвитку OOP / SOLID розробка вприскування стає безладним. Або у вас є точки входу верхнього рівня, що управляють залежностями для декількох рівнів нижче самих себе і передають залежності рекурсивно через побудову, або у вас є …

4
Для чого потрібні рамки для введення залежності? [зачинено]
Я читав більше про принцип інверсії управління та введення залежності, як про його реалізацію, і я впевнений, що я це розумію. Здається, це в основному говорить "не оголошувати членів класу" моменти в класі ". Скоріше, щоб екземпляри повинні бути передані і призначені через конструктор; 'вводиться' у клас із стороннього джерела. …

7
Який "правильний" спосіб впровадження DI в .NET?
Я хочу реалізувати ін'єкцію залежності у відносно великому застосуванні, але не маю досвіду в цьому. Я вивчив концепцію та кілька реалізацій доступних інжекторів IoC та залежностей, таких як Unity та Ninject. Однак є одне, що мені ухиляється. Як я можу організувати створення примірника у своїй програмі? Я думаю про те, …

2
Чи є докази того, що використання ін'єкцій залежностей покращує результати в розробці програмного забезпечення?
Незважаючи на його популярність, чи є якісь емпіричні докази, які показують, що залежність від ін'єкцій (та / або використання контейнера DI) допомагає, скажімо, зменшити кількість помилок, покращити ремонтопридатність або збільшити швидкість розвитку програмних програм у реальному житті?

2
Як ви керуєте конфігурацією із введенням залежності?
Я великий фанат DI / IOC. Він відмінно підходить для поводження / відсторонення важких залежностей і полегшує життя. Однак у мене є невеликий захват, який я не знаю, як вирішити. Основна ідея в DI / IOC полягає в тому, що коли об'єкт інстанціюється, всі його залежності попередньо заповнюються всередині конструктора. …

1
Практика контейнерів / IoC контейнерних практик при написанні фреймів
Я використовував різні контейнери IoC (Castle.Windsor, Autofac, MEF тощо) для .Net у ряді проектів. Я виявив, що вони часто піддаються зловживанням і заохочують ряд поганих практик. Чи існують усталені практики використання контейнерів IoC, особливо при наданні платформи / рамки? Моя мета як розробника фреймворку - зробити код максимально простим і …

3
Продай мене на контейнерах IoC, будь ласка
Я бачив декілька, які рекомендують використовувати контейнери IoC в коді. Мотивація проста. Візьміть наступний код введеної залежності: class UnitUnderTest { std::auto_ptr<Dependency> d_; public: UnitUnderTest( std::auto_ptr<Dependency> d = std::auto_ptr<Dependency>(new ConcreteDependency) ) : d_(d) { } }; TEST(UnitUnderTest, Example) { std::auto_ptr<Dependency> dep(new MockDependency); UnitUnderTest uut(dep); //Test here } В: class UnitUnderTest { …

3
Я отримую ін'єкційну залежність, але чи може хтось допомогти мені зрозуміти потребу в контейнері IoC?
Прошу вибачення, якщо це здається черговим повторенням питання, але кожен раз, коли я знаходжу статтю щодо цієї теми, вона здебільшого просто говорить про те, що таке DI. Отже, я отримую DI, але я намагаюся зрозуміти необхідність контейнера IoC, в який, схоже, потрапляють усі. Чи є сенс контейнера IoC насправді просто …

5
Використання Func замість інтерфейсів для IoC
Контекст: я використовую C # Я створив клас, а для того, щоб виділити його та полегшити тестування, я проходжу всі його залежності; він не має об'єктів миттєвого встановлення внутрішньо. Однак замість посилання на інтерфейси для отримання потрібних йому даних, я маю на ньому посилання на функцій загального призначення, які повертають …

5
Чи потрібно написати інтерфейс API перед реалізацією?
Нещодавно я заглиблювався в більш "організоване" програмування і вивчав, що я повинен програмувати інтерфейс, а не реалізацію. Зважаючи на це, чи було б краще "замалювати" проект в інтерфейсах, перш ніж писати реалізацію для нього, де це можливо? І якщо це так, у випадку використання сторонніх бібліотек (тобто Lidgren), чи потрібно …

5
Чи слідування TDD неминуче призводить до DI?
Я навчився одночасно робити тест-керовану розробку (TDD), впорскування в залежності (DI) та інверсію управління (IoC). Коли я пишу код за допомогою TDD, я завжди закінчую використання DI в конструкторах мого класу. Мені цікаво, чи це через те, як я навчився робити TDD, чи це природний побічний ефект від TDD. Отже, …

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