Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

Инверсия управления используется для увеличения модульности программы и сделать его расширяемым , [1] и имеет применение в объектно-ориентированном программировании и других парадигмах программирования . Этот термин был использован Майклом Маттссоном в диссертации [2], взятой оттуда [3] Стефано Маццокки и популяризованной им в 1999 году в несуществующем проекте Apache Software Foundation, Avalon , который затем получил дальнейшую популяризацию в 2004 году Робертом Мартином и Мартин Фаулер .

Этот термин связан с принципом инверсии зависимостей , но отличается от него, который касается разделения зависимостей между высокоуровневыми и низкоуровневыми уровнями посредством общих абстракций . Общая концепция также связана с программированием, управляемым событиями, поскольку оно часто реализуется с использованием IoC, так что пользовательский код обычно касается только обработки событий, тогда как цикл событий и отправка событий / сообщений обрабатываются фреймворком или среда выполнения.

Обзор [ править ]

Например, при традиционном программировании основная функция приложения может выполнять вызовы функций в библиотеке меню для отображения списка доступных команд и запроса пользователя о выборе одной из них. [4] Таким образом, библиотека вернет выбранную опцию в качестве значения вызова функции, и основная функция использует это значение для выполнения связанной команды. Этот стиль был распространен в текстовых интерфейсах . Например, почтовый клиент может отображать экран с командами для загрузки новой почты, ответа на текущее письмо, запуска новой почты и т. Д., И выполнение программы будет блокироваться до тех пор, пока пользователь не нажмет клавишу для выбора команды.

С другой стороны, при инверсии управления программа будет написана с использованием программной среды, которая знает общие поведенческие и графические элементы, такие как системы управления окнами , меню, управление мышью и т. Д. Пользовательский код «заполняет пробелы» для платформы, например, предоставляет таблицу пунктов меню и регистрирует подпрограмму кода для каждого элемента, но это структура, которая отслеживает действия пользователя и вызывает подпрограмму при выборе пункта меню. . В примере с почтовым клиентом фреймворк может следовать как за вводом с клавиатуры, так и за мышью и вызывать команду, вызванную пользователем любым способом, и в то же время отслеживать сетевой интерфейс.чтобы узнать, поступают ли новые сообщения, и обновить экран при обнаружении сетевой активности. Та же самая структура может использоваться в качестве скелета для программы электронных таблиц или текстового редактора. И наоборот, фреймворк ничего не знает о веб-браузерах, электронных таблицах или текстовых редакторах; реализация их функциональности требует специального кода.

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

Инверсия управления служит следующим целям проектирования:

  • Чтобы отделить выполнение задачи от реализации.
  • Чтобы сфокусировать модуль на задаче, для которой он предназначен.
  • Освободить модули от предположений о том, как другие системы делают то, что они делают, и вместо этого полагаться на контракты .
  • Для предотвращения побочных эффектов при замене модуля.

Инверсию контроля иногда шутливо называют «принципом Голливуда: не звоните нам, мы позвоним вам».

Фон [ править ]

Инверсия управления - не новый термин в информатике. Мартин Фаулер прослеживает этимологию этой фразы до 1988 г. [5], но она тесно связана с концепцией инверсии программ, описанной Майклом Джексоном в его методологии структурного программирования Джексона в 1970-х годах. [6] снизу вверх анализатор можно рассматривать как инверсии сверху вниз синтаксического анализа : в одном случае, управление лежит с анализатором, в то время как в другом случае, он лежит с принимающим приложением.

Внедрение зависимостей - это особый тип IoC. [4] служба поиска , такие как Именование Java и интерфейс каталога (JNDI) аналогично. В статье Лука Бергмана [7] он представлен как архитектурный принцип.

В статье Роберта С. Мартин , [8] принцип инверсии зависимостей и абстракция отводков приходят вместе. Причина, по которой он использует термин «инверсия», заключается в сравнении с традиционными методами разработки программного обеспечения. Он описывает разделение сервисов абстракцией слоев, когда говорит об инверсии зависимостей. Этот принцип используется для определения границ системы в дизайне уровней абстракции.

Описание [ править ]

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

При внедрении зависимости зависимый объект или модуль связывается с объектом, который ему нужен во время выполнения . Какой конкретный объект будет удовлетворять зависимости во время выполнения программы, обычно невозможно узнать во время компиляции с помощью статического анализа . Хотя здесь описывается взаимодействие с объектами, этот принцип может применяться к другим методологиям программирования, помимо объектно-ориентированного программирования .

Чтобы запущенная программа могла связывать объекты друг с другом, объекты должны обладать совместимыми интерфейсами . Например, класс Aможет делегировать поведение интерфейсу, Iкоторое реализуется классом B; программа создает экземпляры Aи B, а затем внедряет Bв A.

Методы реализации [ править ]

В объектно-ориентированном программировании существует несколько основных методов реализации инверсии управления. Эти:

  • Использование шаблона локатора сервисов
  • Например, с помощью внедрения зависимостей
    • Внедрение конструктора
    • Ввод параметров
    • Инъекция сеттера
    • Внедрение интерфейса
  • Использование контекстного поиска
  • Использование шаблонного метода проектирования паттерна
  • Использование шаблона разработки стратегии

В оригинальной статье Мартина Фаулера [9] обсуждаются первые три различных метода. В описании инверсии типов управления [10] упоминается последний. Часто контекстный поиск выполняется с помощью локатора сервисов.

Примеры [ править ]

Большинство фреймворков, таких как .NET или Enterprise Java, отображают этот шаблон:

открытый  класс  ServerFacade  {  общедоступный  < K ,  V >  V  responseToRequest ( K  запрос )  {  if  ( businessLayer . validateRequest ( запрос ))  {  Данные  данных  =  DAO . getData ( запрос );  вернуть  Аспект . convertData ( данные );  }  return  null ;  } }

Этот базовый план на Java дает пример кода, следующего за методологией IoC. Однако важно, чтобы ServerFacadeбыло сделано множество предположений о данных, возвращаемых объектом доступа к данным (DAO).

Хотя все эти предположения могут быть верны в какой-то момент, они связывают реализацию ServerFacadeс реализацией DAO. Разработка приложения способом инверсии управления полностью передаст управление объекту DAO. Тогда код станет

открытый  класс  ServerFacade  {  public  < K ,  V >  V  replyToRequest ( запрос K  , DAO dao ) { return dao . getData ( запрос ); } }

Пример показывает, что способ построения метода respondToRequestопределяет, используется ли IoC. Это способ использования параметров, определяющих IoC. Это напоминает стиль передачи сообщений, который используют некоторые объектно-ориентированные языки программирования.

См. Также [ править ]

  • Слой абстракции
  • Образец архетипа
  • Асинхронный ввод / вывод
  • Аспектно-ориентированное программирование
  • Обратный звонок (информатика)
  • Закрытие (информатика)
  • Продолжение
  • Делегат (CLI)
  • Принцип инверсии зависимостей
  • Программирование на основе потоков
  • Неявный вызов
  • Обработчик прерывания
  • Сообщение передается
  • Монада (функциональное программирование)
  • Образец наблюдателя
  • Опубликовать / подписаться
  • Шаблон локатора услуг
  • Сигнал (вычисление)
  • Программный фреймворк
  • Шаблон стратегии
  • Выход пользователя
  • Шаблон посетителя
  • XSLT

Ссылки [ править ]

  1. ↑ Ральф Э. Джонсон и Брайан Фут (июнь – июль 1988 г.). «Проектирование многоразовых классов» . Журнал объектно-ориентированного программирования, Том 1, номер 2 . Департамент компьютерных наук Университета Иллинойса в Урбане-Шампейне. С. 22–35 . Проверено 29 апреля 2014 года .
  2. ^ Майкл Мэттссон (февраль 1996 г.). «Объектно-ориентированные рамки, обзор методологических вопросов» .
  3. ^ Стефано Mazzocchi (22 января 2004). «Об инверсии управления» . Архивировано 2 февраля 2004 года.CS1 maint: bot: исходный статус URL неизвестен ( ссылка )
  4. ^ a b Внедрение зависимостей .
  5. ^ Инверсия управления на Bliki Мартина Фаулера
  6. ^ «Введение в метод дизайна Джексона» (PDF) .
  7. ^ Архивный указатель на Wayback Machine Inside Architecture: пишите один раз, запускайте где угодно, Лук Бергман
  8. ^ Принцип инверсии зависимости Роберта К. Мартина
  9. ^ Инверсия управляющих контейнеров и шаблон внедрения зависимостей Мартина Фаулера
  10. ^ Типы IoC Архивирован 15 июня 2009 года в Wayback Machine

Внешние ссылки [ править ]

  • Объяснение инверсии управления и пример реализации