IoC, по-видимому, стала краеугольным камнем многих фреймворков и объектно-ориентированных проектов, так как это было описано Мартином Фаулером, Робертом Мартином и другими десять лет назад. Несмотря на свою популярность, IoC неправильно понимается и слишком усложняется.
Посмотрите этот код:
print(book.title());
Это очень прямолинейно: мы извлекаем заголовок из книги и просто передаем его процедуре print (). Контроль в наших руках.
В отличие от этого, здесь есть инверсия:
print(book);
Мы отдаем всю книгу процедуре print (), и она вызывает функцию title (). То есть, мы делегируем контроль.
Это почти все, что вам нужно знать о IoC.
Имеет ли это какое-либо отношение к контейнерам для инъекций зависимостей? Ну, конечно, мы могли бы положить книгу в контейнер, вставить весь контейнер в print (), позволить ему извлечь книгу из контейнера и затем вызвать title (). Но это совсем не IoC - это всего лишь один из его извращенных сценариев использования.
Основной тезис IoC точно такой же, как я предлагал в своих предыдущих постах о голых данных и объектных друзьях: мы не должны иметь дело с данными, только с композицией объектов. В данном примере конструкция была бы еще лучше, если бы мы полностью избавились от процедуры print () и заменили ее на объект:
new PrintedBook(book);
На эту тему говорить больше нечего; Надеюсь, я расчистил ваше понимание.
Комментариев нет:
Отправить комментарий