svenomТо есть с момента публикации статьи понятия Inversion of Control, Dependency Injection и Service Locator как-то принципиально изменились?
При чем здесь вообще это? Я твои скажем прямо, не совсем авторитетные статьи прочитал, а вот ты даже не удосужился взглянуть на мою ссылку, ибо если бы удосужился, может бы наконец осознал, что ты говоришь глупость, точнее не глупость, а не совсем правду.
Сначала пара логических утверждений:
DI это IoC =
true
Если мы говорим про DI, следовательно мы говорим про IoC =
true
Это ты сам себя в чем то убедил видимо, ну да ладно:)
А теперь по поводу вашей фразы, выделенной жирным - к сожалению, она бессмысленна. Поясните вот эти моменты:
1) Что такое "обычный ход выполнения программы"? Значит есть "необычный"? Как их отличить друг от друга и в чем заключаются их характерные черты?
2) Что значит "отдается на откуп фреймворкам"? Вот я попросил Spring заинжектить мне бин? Это "откуп"? А вот я попросил Хибер вытащить мне инфу из БД. Это "откуп"?
Еще раз, максимально сжато: IoC - это способ снижения связанности классов путем делегирования процесса установления зависимсотей между объектами от самих объектов к некому стороннему компоненту. Я не знаю, как это можно еще проще объяснить
Ок, я программист а не писатель и иногда свои мысли доношу не совсем правильно, но постараюсь обьяснить на пальцах. Сам термин Inversion of Control - неужели не наводит тебя на мысль, что
IoC - это способ снижения связанности классов путем делегирования процесса установления зависимсотей между объектами от самих объектов к некому стороннему компоненту - ну скажем так слишком упрощенное определение? Если бы IoC включал только это , то его было бы логичнее назвать Inversion of Instantiation или еще как-либо в этом духе.
Итак, что же такое "обычный ход выполнения программы" - это неудачный перевод термина flow of control of programm. Под этим термином подразумевается процедурный ход выполнения программы, для примера(который кстати у Фаулера),
1.
2.
3.
4.
5.
6.
puts 'What is your name?'
name = gets
process_name(name)
puts 'What is your quest?'
quest = gets
process_quest(quest)
В этом случае твой код всегда находится под твоим контролем, ты решаешь когда задать вопрос, как на него отреагировать, когда завершить программу. Inversion of control происходит когда ты пробуешь перенести свою программу на оконный интерфейс, ты создаешь методы по обработке ввода пользователя, создаешь контролы и биндишь методы на события, тебя больше ничего не волнует. Ты "отдаешься на откуп" оконной системе, именно она будет гонять вечный цикл в ожидании ввода пользователя, диспетчиризации событий и т.п., твой же код будет вызван только тогда когда это будет необходимо, и будет делать только то, что ты указал - таким образом flow of control переходит от тебя к оконной системе(в данном контексте ее можно назвать фреймворком). Все это называется так называемым Принципом Голливуда - не звони нам, мы сами тебе позвоним. Таким образом контроль выполнения инвертирован - не ты вызываешь оконную систему, а она вызывает твои методы, когда нужно, всю работу с инфраструктурой оконная система берет на себя. IoC - это главное отличие библиотек от фреймворков(хотя термин фреймворк тоже достаточно расплывчат), библиотека функций - это набор классов и методов, которые ты непосредственно вызываешь, они делают полезные вещи, а потом возвращают контроль тебе. В отличие от них фреймворки обладают некоторой дополнительной функциональностью и имеют некий абстрактный дизайн, его ты можешь только сконфигурировать, и обьяснить когда и в какие моменты времени фреймворк должен вызвать твой код, это и есть IoC.
Великолепным примером IoC являются EJB2, когда ты создаешь сессионный EJB бин, то ты определяешь методы ejbPassivate() и т.д.. но ты не вызываешь их напрямую, они будут вызваны тогда, когда нужно, тебе не нужно заботиться об этом - опять тот же Принцип Голливуда. Классическим примером IoC кстати является паттерн Template Method, как ни странно.
Не волнуйся, ты не первый кто неправильно трактует этот термин, он очень размыт, но первоначальное его определение было именно таким.
Что касается - автор2) Что значит "отдается на откуп фреймворкам"? Вот я попросил Spring заинжектить мне бин? Это "откуп"? А вот я попросил Хибер вытащить мне инфу из БД. Это "откуп"?
Таким образом, когда Spring инжектит бин - это IoC, когда хибер достает данные из базы - это скорее вызов библиотеки, хотя граница тут очень размыта.
Более того, ServiceLocator исходя из этого, вовсе никакое не IoC, а вот Dependency Injection - да. В общем DI - это всего лишь подмножество IoC, о чем я тебе и пытаюсь обьяснить.
Таким образом декларативные транзакции и управлением скоупами жизни бина - это как раз и есть IoC.
