[code] class bad { public: void doSomething() { f.doSomethingOther(); } private: foo f; } [/code]

[code] class good { public: void doSomething(foo &f) { f.doSomethingOther(); } } [/code]

Это такой баззворд, означающий костылик для недоязычков типа жабки, для решения проблем, которые в нормальных языках навроде Common Lisp не возникают в принципе.

Лисподрочер, иди лесом.

Вот тут вполне доходчиво разъясняется, что это за зверь.

Вообще это очень классная вещь, которая значительно повышает гибкость и настраиваемость системы за счёт уменьшения связности между компонентами.

Ну допустим есть класс Перевозчик, ему нужен Электропоезд для того что-бы перевести что-то куда-то. Электропоезду нужны рельсы, электричество, диспетчер итп. С точки зрения ООП без IoC - инициатива наказуема. Класс Перевозчик должен создать себе поле Электропоезд, добыть для него диспетчера, рельсы, машиниста, проводницу, бельё ну и все дела. С точки зрения здравого смысла - это полный треш.

С точки зрения IoC от Перевозчик требуется запросить Электропоезд у IoC-контейнера, просто сказав, мне нужен Электропоезд, или ещё проще просто Транспортное средство, а откуда оно возьмётся, Перевозчика не волнует.

По сути эта фунциональность будет вынесена в отдельный как правило конфиг.

в итоге имеем классный Separation of Concerns.

На самом деле IoC рекомендуется к использованию повсеместно, в случаях если задача потребовала ООП.

Спасибо тебе, анон!

IoC не путать с (DI) это когда какой-то код вызывается чем-то извне. Это суть всевозможных фреймворков, например когда ты объявляешь обработчик http-запроса, а его уже вызывает http-сервер.

С точки зрения IoC от Перевозчик требуется запросить Электропоезд у IoC-контейнера,

Ты не понял что такое IoC. Да и еще и возможно с DI путаешь.

> Да и еще и возможно с DI путаешь.

Я вообще не вижу особого смысла отрывать одно от другого.

Перевожу: костыль на костыле сидит и костылём погоняет. На Лиспе такое делается в три строчки, и никому в голову не приходит обзывать это модным новым баззвордом. Но для жабки, да, это задача нетривиальная и решается кучей говнокода. Которую для придания ложной солидности непременно надо обозвать «Mega Enterprise Yoba Container».

ООП

IoC-контейнер

Separation of Concerns

Больше баззвордов, ещё больше!

> Лисподрочер, иди лесом.

Я тебе помочь хочу, дурашка. Глаза открыть. А ты в ответ хамишь. Не стыдно тебе?

Прости, дорогой, но у меня глаза больные. А от бесконечного множества скобок у них начинаются жжение и слезоточение.

http://simpleprogrammer.com/2010/11/13/basic-to-basics-what-is-dependency-inv...
http://simpleprogrammer.com/2010/11/16/basic-to-basics-what-is-dependency-inv...

Ога просто ты кроме DI ничего не знаешь.

_________

//wfrr

Одно словосочетание в ссылке dependency inversion намекает на фееричный пипец.

_________

//wfrr

Причем в силу «неявности» действия паттернов реализующих IoC само это IoC является сущим злом.

Кроме куча дурацких последствий, от которых избавлен паттерн Service Locator

_________

//wfrr

Привет, Выфер. Про Service Locator я уже читаю.

//Не скучаешь по ЛОРу?

>Не скучаешь по ЛОРу?

Сидя в нем? Ну все былые завсегдатаи рассосались по углам, остальных научные экскременты модераторов над лоровцами разогнали. Кто сам не ушел того тупо забанили, теперь лор такой чинный и гламурный, даже протухшие посты с матюгами чистят от скуки.

Вообще хотел найти какойнить стольже неадекватный форум с технически грамотным народом, но увы.

_________

//wfrr

белка лучше тут пофлуди http://u.to/dctFAQ

>стольже неадекватный форум с технически грамотным народом, но увы. http://u.to/ErtN ы?

Нульчан, не?

была у меня мысля про rsdn (емнип на sql.ru часть постов дублируется оттуда)

_________

//wfrr

не, на имиджбордах нет ограничений - тупо все заканчивается простым ТХ и интересных тредов не получается.

_________

//wfrr

Ты не понял что такое IoC. Да и еще и возможно с DI путаешь.

Ссылку на отличия не дашь? Или не расскажешь тут? Для меня это вещи из одной плоскости.

// другой anon

>Одной из разновидностей этого принципа является Dependency Injection – Внедрение зависимостей. Иногда между ними ставят знак равенства, хотя строго говоря, это не одно и то же – Inversion of Control является более общим принципом.

Для меня это вещи из одной плоскости.

DI это использование IoC принципа. Одно из. Например сигналы/их обработчики, тоже IoC. Грубо говоря, это когда ты определяешь логику/имплементацию, которая не будет вызываться напрямую (и тем самым не будет связанности), а только через «диспетчеры».

stoplinux? Вроде простое мясо.

>Inversion of Control
Какая-то меметическая зараза, поражающая слабые умы, как и шаблоны.

Твоя программа - набор объектов, которые что-то делают. Установку связей между объектами делает некая отдельная сущность - IoC контейнер. Это и есть IoC. В самом простом случае - обычный самописный объект, который создает все остальные, но обычно это специализирванный фреймворк.

Это очень хорошо. Рад за Лисп. Но что делать с тем фактом, что Лисп не нужен?

Еще один путает DI и IoC.

Нет, я всего лишь правильно отвечаю на очередного лиспера вскочившего в тред с пиханием лиспа во все дыры

Просто не корми тролля (или лиспопалладина, один хрен).

> Еще один путает DI и IoC.

А как их не путать, ведь когда говорят IoC - подразумевают DI, когда говорят DI - подразумевают IoC.

А стремление любой SoC называть IoC-ом я не разделяю. В широком понимании и MVC - IoC, и делегирование - IoC, и функции высших порядков - IoC, да и вообще передача параметра в функцию - IoC.

Everything is IoC :)

Предлагаю всё-таки остановиться и под IoC подразумевать наличие фактори, который предоставляет вам нужный инстанс. Что там внутри, ручками ли всё склеено, сервис-локатором или аннотациями, конфигом и рефлексией - это дело пятое.

>Предлагаю всё-таки остановиться и под IoC подразумевать наличие фактори, который предоставляет вам нужный инстанс.

Имхо, это как раз не IoC.

Everything is IoC :)

Бррр, нет. ^)

Спасибо большое

Everything is IoC

Все что не вызывается напрямую, да. Что в этом странного? Не надо боятся такого широкого определения, ибо большинство таких практик сильно неявные и сильно усложняют понимание, поэтому не так широко распространены.

IoC - это общее понятие. Попросту говоря «не зови меня, я сам тебя вызову» (принцип Голливуда).

Dependency Injection - частный случай IoC, когда ты не тянешь зависимости ручками, а они сами откуда-то приходят.

Dependency Inversion - обращение зависимостей путем введения интерфейсов.

Dependency Injection (на ряду с ServiceLocator) часто применяется для реализации принципа Dependency Inversion. Хотя я часто использую Dependency Injection без Dependency Inversion (т.е. не ввожу интерфейсы, а тяну прямо реализации) ибо верю в силу рефакторинга :)

IoC существует столько же, сколько и Лисп, если не больше. Это вообще один из базовых приемов программирования. И в Лиспе этот принцип используется.

Причем в силу «неявности» действия паттернов реализующих IoC само это IoC является сущим злом

Мож ты плохой либой пользовался? Юзаю Google Guice - очень нравится. И особенно по тому, что стектрейсы он при ошибках кидает очень читабельные.

Встряну

Всем разбирающимся в теме - а вот на конкретном примере можно показать, как правильно всё это юзать? Ну как первый анонимус сделал. Например, как с IoC-подходом сделать вот такое:

class Building {
QList <Floor*> m_floorList;
...
void addEmptyFloor() {
m_floorList.append(new Floor());
}
...
};

IoC обычно используется для построения «каркаса» приложения, т.е. объектов-синглтонов (которые обычно stateless, у кого не stateless - тот ссзб). Для создания неких динамических структур с соблюдением Dependency Inversion обычно применяется Abstract factory. Сами фабрики же инъектятся через IoС фрейморк. Хотя можно использовать в качестве фабрики и напрямую возможности IoC-контейнера. Но это имхо изврат.

В твоем случае я не вижу смысла ни в Dependency Injection ни в Dependency Inversion.

Спасибо большое! Камень с души :) Тогда вот что интересно - какую литературу посоветуете по всем перечисленным вещам вроде Abstract Factory? я так понимаю, это паттерны же, т.е. «банду четырех» курить надобно?

Вместо IoC надо читать DI, но как ты понимаешь пофигу Guice или спринг, ни в каком из этих случаев нельзя написать так:

class Provider {
  @Inject
  private /*static?*/ final Consumer consumer;

  Provider() {}
 // do something with injected consumer
}

// и так

class Worker implements Runnable {
  public Worker() {}
  
  public void run() {
    final Consumer consumer;
    // do something with consumer
  }
 
}

эти ситуации непозволяются языком, придется выносить локальну переменную в приватное поле (хотя это противоречит дизайну - она там не нужна), а финальную вообще выставлять через конструктор - как итог мы теряем возможность прозрачного создания объектов - требуется городить тучу фабрик. А если объект создается через фабрику то какой нахрен IoC?

С SL таких проблем не будет.

_________

//wfrr

>IoC обычно используется для построения «каркаса» приложения, т.е. объектов-синглтонов (которые обычно stateless, у кого не stateless - тот ссзб).

Ога ога, а state у нас сидит в субд, это ынтрепрайзно. Не путай теплое с мягким.

_________

//wfrr

Да там вроде все просто. Мне в свое время статьи на википедии хватило.

Чет не понял нифига. Приведи плиз конкретный пример использования SI, который нельзя реализовать с помощью DI.

Мне иногда кажется, что GoF уже сами не рады, что когда-то написали пресловутую книгу. То, что было писано как сборник рецептов, типа «хозяйке на заметку», превратилось чуть не в евангелие, и все с ним носятся, как зомбированные. Этим не так надо пользоваться. Это надо было прочитать один раз в 18 лет, потом задуматься, а потом в результате научиться СВОЕЙ ГОЛОВОЙ ДУМАТЬ, блджад. А не молиться на чужие паттерны и не устраивать религию с пророками типа фаулера, да приимет его биореактор. Потому что паттерны - это ограничения мышления, когда всё на свете пытаются в них втиснуть и подогнать под шаблон. И ещё богословские диспуты: что такое «Хренофиглос», тождественен ли он «Триаде Опердениуса» и т. д. Потому что, если суть понятия нельзя передать тремя словами так, чтобы все поняли, то место ему исключительно в головах сектантов, а не в науке и технике.

Ну, мне на примерах понятнее как-то, чем абстрактное бла-бла-бла. Впрочем ладно, буду читать.

ну если исходный код тебе непонятен то что уж говорить то?

_________

//wfrr