Обсуждение:Инверсия управления
Проект «Информационные технологии» (уровень III, важность для проекта средняя)
Эта статья тематически связана с вики-проектом «Информационные технологии», цель которого — создание и улучшение статей по темам, связанным с информационными технологиями. Вы можете её отредактировать, а также присоединиться к проекту, принять участие в его обсуждении и поработать над требуемыми статьями. |
 | Эта статья выставлялась на удаление и была оставлена. Пояснение причин и соответствующее обсуждение вы можете найти на странице Википедия:К удалению/15 апреля 2008. Повторное выставление допустимо лишь при наличии аргументов, не рассмотренных в прошлых номинациях, при изменении обстоятельств вокруг предмета статьи или изменении правил Википедии, в противном случае повторная заявка будет быстро закрыта. |
Нужно бы картинку из англиийской достать...
Описание
правитьОткуда взялось это чудовищное описание? (которое не объясняет, но при этом усложняет и запутывает)
Ссылка ведет на статью http://martinfowler.com/articles/injection.html, но там такого текста я не нашел (там вообще нет даже упоминания про фабрику и компоновщик)...
О названии
правитьСтранно звучит "Обращение контроля", лучше использовать термин "Инверсия управления"
91.77.225.84 13:34, 26 апреля 2008 (UTC) Хайретдинов Д. И.
- Всегда лучше использовать русские термины там, где это возможно. Кажется, что лучше в данном случае будет "Обращение управления" --DpakoH 08:19, 9 мая 2008 (UTC)
- Важно, на мой взгляд, не слово Inversion, а слово Control, которое переводится как Управление, и никогда не переводится как Контроль, предлагаю статью переименовать.--90.189.173.121 17:06, 22 марта 2009 (UTC)
В статье Ложные друзья переводчика control правильно переводится как управление.
Определение IoC через DI в корне неверно
правитьСуть IoC не в вынесении/внесении/внедрении(выбирайте любой термин на свой вкус) зависимости, а в обращении контроля над выполняемыми действиями. Dependency Injection это только одно из применений IoC.
Пример принципа IoC: Класс "А" отдаёт управление классу "Б", класс "Б" вызывает методы класса "А".
Пример DI: В процессе реализации программного продукта в классы "А" и "Б" вносится зависимость от интерфейса "И", которая позволяет избежать жёсткого связывания классов "А" и "Б". "А" реализует интерфейс "И", что позволяет вынести класс "Б" в отдельную библиотеку и изменять "А" с "Б" независимо. При этом управление зависимостью отдаётся(вот тут и наблюдаем IoC) внешнему механизму, пусть это будет класс "В" в библиотеке с классом "Б".
Почувствуйте разницу. Первое - абстрактный принцип. Второе - практическое применение этого принципа. Применения могут быть и другими.
ThermIt 12:31, 6 октября 2008 (UTC)
На самом деле DI есть основная реализация Обращения Управления (IoC). Поэтому эти понятия и стали синонимами.91.77.16.143 20:28, 25 июня 2009 (UTC)91.77.16.143 20:29, 25 июня 2009 (UTC)
--Goleon 13:21, 14 мая 2010 (UTC) Существует несколько реализаций IoC. В частности шаблон Factory является реализацией IoC: контроль для установления зависимости отдается фабрике. Также service lookup является реализацией принципа IoC: контроль предоставляется сервису. DI также реализует принципы IoC и некорректно приравнивать IoC и DI.
IOC это вообще очень общее понятие - например есть консольное приложение которое запрашивает ввод, а мы его заменяем оконным приложением с message dispatcher loop - тогда мы делегируем управление операционной системе. И не важно swing это или winforms или сервлет - принцип совершенно общий. То что описано в статье - это Dependency Inversion Principle. Dependency Injection это еще одно понятие где мы применяем IoC для внедрения зависимостей короче, только больше путаницы эта статья вносит. 83.149.9.10 12:09, 26 ноября 2012 (UTC)Борис
Akudrevatykh 17:42, 29 мая 2014 (UTC) Даже Фаулер в приведенной ссылке говорит, что многие люди почему-то ставят равенство между DI и IoC, хотя он сам объясняет его при помощи классического listener-а. Кроме того, формулировка, приведенная в статье вообще неверна - IoC чудесно реализуется без ООП, программирования через интерфейсы и прочего. На мой взгляд главное, что есть в IoC - это принцип "наш код не будет вызывать что-то, пусть что-то другое вызывает нас", и тогда сразу становится понятно, каким образом listener-ы, фабричные методы и DI реализуют IoC, а также причем здесь инверсия.
Думаю, это стоит вынести в первый абзац статьи :-) Коммунар (обс.) 12:34, 12 сентября 2018 (UTC)наш код не будет вызывать что-то, пусть что-то другое вызывает нас
Pavelpat 22:14, 15 марта 2015 (UTC) Уже несколько лет эта статья вносит путаницу в термин IoC.
- Похоже, IoC может обойтись не только без DI, но и без ООП, как архитектурное решение. А где сейчас в статье определение через DI? Просто констатируется, что это - одна из распространенных реализаций, на что и источник легко находится. РоманСузи 05:27, 16 марта 2015 (UTC)
Реализации
правитьНеобходимо как-то определиться, сколько их там будет, и на основании каких АИ. А так этот список может погибнуть при очередной чистке. РоманСузи 13:35, 31 декабря 2012 (UTC)