LINUX.ORG.RU

Что есть Inversion of Control?


0

2

Для чего нужно, в каких ситуациях стоит применять? Нашел статью в вики, но там не очень развернуто: буквально написано «это такая-то технология» и перечислены основные реализации.

Всем спасибо.

Ответ на: комментарий от ma1uta

хм, разумные советы в перемежку с воспоминаниями быдлокодера, java-style?

shty ★★★★★
()
Ответ на: комментарий от anonymous

На Лиспе такое делается в три строчки

на лиспе всё делается в 3 строчки, только сложность фрактальная

shty ★★★★★
()
Ответ на: комментарий от dizza

Использование SL: [code] Consumer consumer = ServiceLocator.get(Consumer.class); [/code]

в любом месте. очевидно, не правда ли? _________

//wfrr

anonymous
()
Ответ на: комментарий от dizza

Использование SL:

Consumer consumer = ServiceLocator.get(Consumer.class);

в любом месте. очевидно, не правда ли? _________

//wfrr

anonymous
()
Ответ на: комментарий от anonymous

Очень странное желание использовать инфраструктурные элементы вроде SL для реализации бизнес логики. Зачем скрывать получение Consumer-а Producer-ом? Если уж они знают друг о дружке, почему бы это не выразить явно в виде аргумента конструктора? Если тебе кажется, что там не нужны поля а именно локальные переменные, то это твои какие-то заморочки. И кстати говоря, если уж очень сильно хочется, то Guice (как и Spring) можно использовать как SL держа статическую ссылку на инстанс контекста и дергая ее где нужно, т.е. что-то вроде Consumer consumer = InjectorHolder.getInjector().getInstance(Consumer.class);

dizza ★★★★★
()
Ответ на: комментарий от dizza

Очень странное желание использовать инфраструктурные элементы вроде SL для реализации бизнес логики.

Детка, забудь про ынтерпрайз, нет никакой бизнес логики, ты не на работе. Есть ПО. В нем тупая задача - надо получить сервис, и что -то с ним сделать, обязательно нехорошее такое.

Зачем скрывать получение Consumer-а Producer-ом? Если уж они знают друг о дружке, почему бы это не выразить явно в виде аргумента конструктора?

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

Если тебе кажется, что там не нужны поля а именно локальные переменные, то это твои какие-то заморочки

Паттерны съели твой моск, если переменная используется только внутри метода то это локальная переменная, и только кретины ее будут выносить _просто так_ в поля.

И кстати говоря, если уж очень сильно хочется, то Guice (как и Spring) можно использовать как SL держа статическую ссылку на инстанс контекста и дергая ее где нужно

И получить «Суперсинглтон» и фокусы с загрузкой классов.

_________

//wfrr

anonymous
()
Ответ на: комментарий от anonymous

Есть ПО. В нем тупая задача - надо получить сервис, и что -то с ним сделать, обязательно нехорошее такое.

А знаем, знаем, это когда весь код выглядит как инфраструктурный. Не пиши так никогда.

Пипец, а нахрена тогда городить все эти DI, если у нас они друг о друге все знают?

Не знаю зачем тебе, но я обычно использую DI для отделения кода конфигурации от всего остального кода раз, и с целью создания тестовой конфигурации два.

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

Тут ты очень нескладно выражаешь свои мысли, так что не распарсил.

если переменная используется только внутри метода то это локальная переменная, и только кретины ее будут выносить _просто так_ в поля.

Тем что ты ее локально вытаскиваешь через SL ты просто скрываешь тот факт, что она на самом деле не локальная. Так что полем она должна быть не просто так, а потому, что одна сущность знает про другую, это нормально. И в таком случае не ясно кому еще паттерны мозг съели :)

dizza ★★★★★
()
Ответ на: комментарий от dizza

>А знаем, знаем, это когда весь код выглядит как инфраструктурный.

Тебе не говорили что ты похож на свою аватару? (но не аватара на тебя)

но я обычно использую DI для отделения кода конфигурации от всего остального кода раз, и с целью создания тестовой конфигурации два.

Убогенько, а обычно его используют для повышения модульности прочих блабла бла связанных с повторным использованием кода.

Тут ты очень нескладно выражаешь свои мысли, так что не распарсил.

Может тебе еще принципы дизайна разжувать? Почитай http://ru.wikipedia.org/wiki/Божественный_объект

Тем что ты ее локально вытаскиваешь через SL ты просто скрываешь тот факт, что она на самом деле не локальная.

Попробуй расширить свое сознание до того факта что SL может возвращать не синглтон. Вообщето. А еще до конфигурабельности.

Так что полем она должна быть не просто так

Кончай бредить, причины ты так и не назвал.

а потому, что одна сущность знает про другую, это нормально

Упоминание слова мозг в отношении тебя уже является лестью, как я посмотрю. Когда очнешься почитай про типы зависимостей, в частности чем отличается «использует» - в нашем случае, от «включает».

_________

//wfrr

anonymous
()
Ответ на: комментарий от anonymous

Попробуй расширить свое сознание до того факта что SL может возвращать не синглтон

Попробуй и ты расширить свое сознание до факта, что и DI может возвращать не синглтон и более того он может формировать инстанс на лету в зависимости от контекста вызова (см Provider из JSR 330)

Когда очнешься почитай про типы зависимостей, в частности чем отличается «использует» - в нашем случае, от «включает».

Все таки ты повернутый на паттернах. Я вашу терминологию не очень знаю, но «включение» ты откуда-то высосал. В твоем примере речь идет о агрегации, а не «включении». Эту самую агрегацию я и имел в виду, говоря что одна сущность знает про другую.

dizza ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.