The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
IoC кажется стал угловым камнем многих фреймворков и объектно-ориентированных дизайнов, с тех пор как его описали Мартин Фаулер, Роберт Мартин и другие десять лет назад. Несмотря на его популярность, IoC часто неправильно понимается и излишне усложняется.
print(book.title());
Это очень просто: мы получаем заголовок из книги и просто передаем его процедуре print(), или чему-то другому. Мы контролируем, у нас в руках все решение.
В отличие от этого, вот инверсия:
Мы передаем всю книгу процедуре print(), и она вызывает title() по своему усмотрению. То есть мы делегируем управление.
Это практически все, что вам нужно знать об IoC.
Есть ли у этого что-то общее с контейнерами внедрения зависимостей? Конечно, мы могли бы поместить книгу в контейнер, внедрить весь контейнер в print(), позволить ему извлечь книгу из контейнера и затем вызвать title(). Но это не то, о чем на самом деле говорит IoC - это всего лишь один из его искаженных сценариев использования.
Основная идея IoC точно такая же, какую я предлагал в своих предыдущих сообщениях о голых данных и дружественных объектах: мы не должны иметь дело с данными, а только с композицией объектов. В данном примере дизайн был бы еще лучше, если бы мы полностью избавились от процедуры print() и заменили ее объектом:
Это было бы чистое составление объектов.
Больше нет ничего сказать на эту тему; я надеюсь, что я прояснил это для вас — все так просто.
Translated by ChatGPT gpt-3.5-turbo/42 on 2024-01-09 at 18:09
