Много преимуществ, и да можно менять xml без переклмпиляции. К тому же смотри такой пример - тебе нужны реальные сервисы для продакшена, и стабовые для теста,все они имеют одинаковый интерфейс. ты описываешь их в 2 разных xml. Далее допустим когда ты запускаешь тесты ты можешь одной строкой поменять целую группу сервисов, просто поменяв имя включаемого файла. Далее IOC позволяет декларативно настроить транзакции, скоупы жизни бинов и т.д. и т.п. И да, почитай таки Фаулера)

svenom, ты часом DI и IoC не путаешь?:) Декларативное описание транзакций и скоупов по сути и есть inversion of control.

jab. в твоем примере IoC в принципе избыточен - потому что ты работаешь с сущностью(автомобилем), IoC рулит когда тебе надо заинжектить сервисы, дао и тому подобную муть, которая зачастую и есть синглтоны, тут ты прав. Все принципы надо использовать без фанатизма

:) Ты все-таки не понимаешь чем они отличаются. Все то что ты красиво описал - это и есть Dependency Injection, а вот IoC это как раз более масштабный принцип, следуя которому некоторую специфическую часто повторяющуюся логику(зачастую инфраструктурную) обособляют от так называемой бизнес-логики, вот почему декларативное управление транзакциями это часть IoC, насчет скоупов ты даже сами себе противоречишь, утверждая что IoC - одна из методик уменьшения связанности между объектами, так вот избавление от контроля за циклом жизни объектов, это и есть ничто иное, как методика уменьшения связанности между объектами. И да, DI это вовсе никакая не реализация IoC, а всего лишь его подмножество. Сами же советовали Фаулера, а то человек почитает вас и примет ваши догадки за истину.

Ты бы вместо того чтобы нервничать и подсовывать ссылки на статьи, в которых вначале прям таки написано что эта информация устаревшая, почитал бы все-таки Фаулера, раз я для тебя не авторитет) и пораскинул мозгом. http://martinfowler.com/bliki/InversionOfControl.html. Все что делается не внутри обычного хода выполнения программы, а отдается на откуп фреймфоркам или контейнерам и есть IoC, а ты мне все про DI втираешь:)

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. Под этим термином подразумевается процедурный ход выполнения программы, для примера(который кстати у Фаулера),



В этом случае твой код всегда находится под твоим контролем, ты решаешь когда задать вопрос, как на него отреагировать, когда завершить программу. 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.

Visitorом тут не пахнет. Как и Hot swap.

Factory кстати есть - только это скрыто от наших глаз:)

Если ты не видел мы занудим тут уже не первый день:)

svenom, чтобы стать синглтоном - объект то должен кто-то создать? То же самое с пулом. Прототип тоже не подходит в этом случае. А вот newInstance() и привидение к интерфейсу, где-то внутри спринга как раз есть) Хотя этот спор бессмысленен, потому что он бестолковый)

Не, это всего лишь делегирование

А кто говорил про классическую фабрику? Ты опять что-то придумал. Я ж не спорю что ты знаешь много creational patternов, я их тоже знаю - и когда и зачем использовать. Если быть точным, то спринг использует что-то вроде фабрики в сочетании с object pool, но опять же спор ни о чем.