Comments 25
Хороший перевод, большое спасибо автору.
Познавательно… вот только в чем мораль? Я не понял)
Слишком много воды в конце. В таких делах нельзя без примеров, иначе все в кашу в голове превращается.
Вроде примеров как раз достаточно.
Это перевод статьи Фаулера, который, как считается, широко формализовал такие понятия как IoC и DI.
Это перевод статьи Фаулера, который, как считается, широко формализовал такие понятия как IoC и DI.
Фаулера, который, как считается, широко формализовал такие понятия как IoC
А ещё Фаулер задавался вопросом
The question, is what aspect of control are they inverting?/blockquote>
У меня, если честно, тоже возникает такой вопрос когда я слышу про IoC. Тот же пример про шаблонный ментод. Экземпляр класса всё так же вызывает метод экземпляра класса-участника иерархии с шаблонными методами. В чём инверсия? Где поменялось направление?
Имхо, изменение нужно искать не на уровне выполнения кода, а на уровне дизайна. В случае с шаблонным методом, когда сам шаблонный метод уже зафиксирован, мы больше явно не можем задать какие функции нужно позвать в каком порядке, т.е. в некотором смысле теряем контроль. Стоит ли называть это инверсией или каким-нибудь другим словом — уже другой вопрос :)
Серёьзно) я не вижу инверсии управления.
Вася говорит Пете что делать
Петя говорит Васе что делать
Инверсия управления.
В случае с шаблонным методом — я его действительно не вижу класс-клиент как вызвал методы исполнителя так и вызывает.
Вася говорит Пете что делать
Петя говорит Васе что делать
Инверсия управления.
В случае с шаблонным методом — я его действительно не вижу класс-клиент как вызвал методы исполнителя так и вызывает.
Я не вижу «инверсии», но вижу разницу.
Ещё раз, изменения на уровне выполнения нету. Конечно, заменили один метод другим, он как вызывался так и вызывается.
Отличие видно, когда мы пишем код, а не выполняем его. Когда я просто пишу последовательность команд, я всё контролирую (когда и какие функции позвать). Когда я использую написанный ранее шаблонный метод, мой контроль над вызовом функций ограничен => потеря контроля.
Ещё раз, изменения на уровне выполнения нету. Конечно, заменили один метод другим, он как вызывался так и вызывается.
Отличие видно, когда мы пишем код, а не выполняем его. Когда я просто пишу последовательность команд, я всё контролирую (когда и какие функции позвать). Когда я использую написанный ранее шаблонный метод, мой контроль над вызовом функций ограничен => потеря контроля.
Добавил примеры. В случае шаблонного метода Фаулер рассматривает JUnit. Мы реализуем методы setUp, tearDown, добавляем тесты (методы testBlaBlaBla), затем для запуска тестов выполняем:
В итоге мы вызываем JUnit, но не вызываем наши методы, JUnit вызывает их, следовательно происходит явление инверсии управления.
TestRunner.run(SomeTest.class);
В итоге мы вызываем JUnit, но не вызываем наши методы, JUnit вызывает их, следовательно происходит явление инверсии управления.
Примеры только в начале. Дальше идет рассказ про .net (если бы я не знал, как они там устроены через делегаты, то ничего бы не понял), после чего идет про непонятно что плюс это еще и перевод, так что возможно не все передано точно.
Как бы хорошо не было формализованно, без примеров понять сложно, особенно когда все в новинку, в пример можно привести учебники математики, где идут подряд одни теоремы на формальном математическом языке. Понять вроде можно, но дается это все с трудом.
Как бы хорошо не было формализованно, без примеров понять сложно, особенно когда все в новинку, в пример можно привести учебники математики, где идут подряд одни теоремы на формальном математическом языке. Понять вроде можно, но дается это все с трудом.
По-русски IoC традиционно называется «обращение контроля».
Первый раз слышу такое «традиционное» определение
А еще более традиционно IoC называется Ioc
Я все-таки поясню свою позицию. Я против перевода подобных терминов, потому что они порождают перлы вроде ППП (Повсюду Протянутая Паутина). Из-за таких вот переводов технические книги на русском читать невозможно. По-моему как-то на Хабре писали, что в Южной Корее термины не переводятся и к тому же произносятся правильно по-английски (а не как у нас — на российский лад) — вот это классная тема.
«Инверсия управления» точнее отражает суть явления
Воообще-то, это банальные callback. Но «инверсия управления» звучит круче, если хочешь продать свой фреймворк (:
Callback — это лишь одна из разновидностей IoC
Старый и бессмысленный холивар про паттерны и ООП: классы — это замыкания для бедных, или замыкания — это классы для бедных? IoC — это многословное описание костылей, которые приходится применять из-за отсутствия в языках нормальной поддержки функциональщины, или базовый принцип, а функциональный подход обеспечивает одну из возможных реализаций?
Чтоб в нем участвовать осмысленно, лучше попробовать пописать и так, и так, истина imho где-то посередине все равно.
С «принципом Голливуда» проблем так-то тоже ведь много, и если можно, то его лучше избегать, а применять только осознанно и при необходимости (это, впрочем, для многих других паттернов справедливо): в данном случае, если не ты звонишь, а тебе звонят, то из контекста понять, что делает конкретный кусок кода, становится сложно, нужно держать всю систему в голове.
Чтоб в нем участвовать осмысленно, лучше попробовать пописать и так, и так, истина imho где-то посередине все равно.
С «принципом Голливуда» проблем так-то тоже ведь много, и если можно, то его лучше избегать, а применять только осознанно и при необходимости (это, впрочем, для многих других паттернов справедливо): в данном случае, если не ты звонишь, а тебе звонят, то из контекста понять, что делает конкретный кусок кода, становится сложно, нужно держать всю систему в голове.
Возможно, просто тема не стоит отдельного топика. callback'и как частный случай IoC или наоборот — не суть важно. Эти принципы используются настолько часто, что о них не знает только ленивый. Даже в голову не пришло бы придумывать на этот счёт какую-то особую философию со своим названием. В большинстве мануалов и книг я вижу термин callback, и именно о таком применении идёт речь в статье.
Вот уж правда бессмысленный холивар. Это же семантическая относительность, прям как в физике: смотря, что берем за точку отсчета.
А про коллбэк я хотел сказать, что IoC не ограничивается коллбэками. Если, конечно, не называть коллбэками в том числе и шаблонные методы.
А про коллбэк я хотел сказать, что IoC не ограничивается коллбэками. Если, конечно, не называть коллбэками в том числе и шаблонные методы.
Как по мне, статья для теоретиков. В плане практического применения гораздо полезнее почитать его же Dependency Injection.
Перевел статью, так как очень мне понравилась. Многие (я тоже до некоторого времени) путают такие принципы как dependency injection и inversion of control. Фаулер в этой статье четко определяет последнее, показавая что dependency injection это всего лишь частный случай реализации inversion of control. Также начал было уже переводить его статью Inversion of Control Containers and the Dependency Injection pattern, но нашел уже готовый перевод в сети
После прочтения в мозгу что-то щелкнуло и все встало на свои места.
Спасибо.
P.S. Ну вот почему нельзя было таким простым и понятным языком написать в Википедии?
Спасибо.
P.S. Ну вот почему нельзя было таким простым и понятным языком написать в Википедии?
Sign up to leave a comment.
Инверсия управления/Inversion of Control