Лекция
Привет, Вы узнаете о том , что такое инверсия управления, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое инверсия управления, inversion of control, ioc , инъекция зависимости , неявный вызов , настоятельно рекомендую прочитать все из категории Объектно-ориентированное программирование ООП.
инверсия управления (англ. Inversion of Control, IoC) — важный принцип объектно-ориентированного программирования, используемый для уменьшения зацепления в компьютерных программах . Также архитектурное решение интеграции, упрощающее расширение возможностей системы, при котором контроль над потоком управления программы остается за каркасом .
Инверсия управления - это парадигма проектирования, целью которой является снижение осведомленности о конкретных реализациях из кода инфраструктуры приложения и предоставление большего контроля компонентам вашего приложения, специфичным для предметной области. В традиционной системе, спроектированной сверху вниз, логический поток приложения и понимания зависимостей переходит от верхних компонентов, разработанных первыми, к последним разработанным. Таким образом, инверсия управления - это почти буквальное изменение контроля и понимания зависимостей в приложении.
Термин «инверсия управления» был популяризирован в 1998 году Стефано Маццокки как следствие попытки разработать «Java Apache Server Framework» для растущего набора серверных компонентов и инструментов Java в Apache . Sun только начинала защищать слово Java, когда оно использовалось для обозначения / наименования программного обеспечения и вычислительных функций, поэтому Apache пришлось искать альтернативные имена. В качестве названия проекта был выбран Avalon (очередь изображений легенды о короле Артуре .
Команде Avalon было ясно, что компоненты, получающие различные аспекты сборки , конфигурации и жизненного цикла компонентов , превосходят те компоненты, которые сами собираются получить то же самое.
Важно отметить, что инициатива Open Services Gateway (OSGi) также была начата примерно в то же время, что и фреймворк Avalon, и в некоторой степени была похожа. Он родился в Европе и определен / контролируется фондом, сформированным вокруг него.
В последнее время этому типу IoC было присвоено новое имя - Contextualized Dependency Lookup.
Avalon был отменен как проект Apache в 2004 году Apache Software Foundation.
Одной из реализаций IoC в применении к управлению зависимостями является внедрение зависимостей (англ. dependency injection) . Внедрение зависимости используется во многих фреймворках, которые называются IoC-контейнерами.
Если сравнить с более низкоуровневыми технологиями, IoC-контейнер — это компоновщик, который собирает не объектные файлы, а объекты ООП (экземпляры класса) во время исполнения программы. Очевидно, для реализации подобной идеи было необходимо создать не только сам компоновщик, но и фабрику, производящую объекты. Аналогом такого компоновщика (естественно, более функциональным) является компилятор, одной из функций которого является создание объектных файлов. В идее компоновки программы во время исполнения нет ничего нового. Предоставление программисту инструментов внедрения зависимостей дало значительно бо́льшую гибкость в разработке и удобство в тестировании кода .
Инверсия управления может использовать внедрение зависимостей, потому что для создания компонентов, обеспечивающих определенные функциональные возможности, необходим механизм. Существуют и используются другие опции, например, активаторы, фабричные методы и т. Д., Но фреймворкам не нужно ссылаться на эти служебные классы, когда классы фреймворка могут вместо этого принять нужную (ые) зависимость (и).
Внедрение зависимостей - это шаблон, используемый для создания экземпляров классов, на которые полагаются другие классы, не зная во время компиляции, какая реализация будет использоваться для предоставления этой функциональности.
Джо Уолнес , Майк Кэннон Брукс и другие начали писать XWork и WebWork2 в поддержку своей будущей книги « Программирование с открытым исходным кодом Java» . Об этом говорит сайт https://intellect.icu . Джо отметил, что концепции были очень похожи на концепции IoC / Avalon, которые Пол пытался убедить Джо принять в течение нескольких лет, но зависимости передавались в компонент через сеттеры. Необходимость этих зависимостей была объявлена в некотором сопроводительном XML.
Пол, который работал с Джо в компании по торговле энергоносителями в Лондоне, предположил, что это «второй тип» инверсии контроля. IoC типа 2, как термин, конечно же, устарел для «Setter Injection».
Род Джонсон , руководитель Spring Framework, написал книгу Expert One-on-One J2EE Design and Development (опубликована в октябре 2002 г.), в которой также обсуждались концепции внедрения установщика и представил строку кода, которая в конечном итоге стала Spring Framework на SourceForge в феврале 2007 г. 2003 г.
Мартин Фаулер предположил, что, возможно, лучше иметь такие методы разрешения зависимостей с префиксом init, а не сеттером. С помощью префиксов init или set для методов получения зависимостей контейнер может автоматически собирать компоненты SDI без манифеста. SDI, находящийся под контролем контейнера, лучше всего работает с манифестом. Без контейнера компоненты SDI очень похожи в использовании на простые Java-бины:
Обратной стороной прямого пользователя bean-компонента SDI-компонента является то, что можно создать экземпляр компонента без установки всех зависимостей. Как ошибки, они должны быть довольно быстро обнаружены после компиляции с помощью простого теста этого приложения. Однако через несколько месяцев, когда пакет компонентов заменяется в приложении последней версией того же самого, новая зависимость может быть пропущена, и нефункционирующее приложение может быть отправлено в эксплуатацию. Опять же, это может быть обнаружено путем тщательного тестирования.
Рэйчел Дэвис, как одна из восторженных рецензентов книги Джо, оставила заметку на полях для абзацев, в которых обсуждалась элегантность второго типа. Заметка о полях просто предполагала, что разрешение зависимостей конструктором было более элегантным. В последнее время мы склонны соглашаться. В то время (весна 2003 г.) не было реализации идеи внедрения конструктора, поэтому для первых руководителей PicoContainer (Пола Хамманта и Аслака Хеллесоя), которым эта идея понравилась, казалось логичным начать проект.
Дополнительным преимуществом является то, что компоненты CDI не могут быть созданы с отсутствующими зависимостями. Таким образом, компилятор или IDE обнаружат несоответствия между любым конструктором и параметрами, переданными в класс при создании экземпляра.
ATG Dynamo был коммерческим продуктом, который имел успех на рынке в конце 90-х. Он также использовал конструкторы для разрешения зависимостей. Коммерческий успех Dynamo немного изменился, когда Apache создал Struts, но не следует забывать, что Dynamo сначала случайно использовал конструкторы для зависимостей в веб-приложениях.
В 2003 году Пол называл стиль IoC Avalon «типом 1», сеттер - «типом 2», а конструктор - «типом 3». Он дошел до публикации статьи об этом в Java Developer Journal.
Декабрь 2003 г . ; Род Джонсон из команды Spring Framework, Пол Хаммант (бывший Avaloner и со-руководитель PicoContainer), Майк Ройл и Мартин Фаулер (по электронной почте) высказались и поиграли с некоторыми из формулировок предстоящей статьи Мартина. Мартин написал черновик этой статьи совершенно независимо от этой команды, но любезно показал им черновик. Проблема, с которой столкнулась команда, заключалась в названии шаблонов, связанных с инверсией управления, и примерах использования, которые показал Мартин. Род уже использовал фразу «Внедрение» раньше, поэтому было сочтено, что стиль разрешения компонентов «Внедрение зависимостей» был бы хорошей идеей.
Таким образом, когда Dependency Injection правильно взяла верх:
Тип 1 становится контекстным поиском зависимостей
Тип 2 становится инъекцией зависимостей сеттера
Тип 3 становится инъекцией зависимостей конструктора
Тип 4 был инъекцией поля или инъекцией геттера, в зависимости от того, с кем вы говорили.
Шаблоны инверсии управления (IoC) и внедрения зависимостей (DI) предназначены для удаления зависимостей из вашего кода.
Например, предположим, что в вашем приложении есть компонент текстового редактора, и вы хотите обеспечить проверку орфографии. Ваш стандартный код будет выглядеть примерно так:
То , что мы сделали здесь , создает зависимость между TextEditorи SpellChecker. В сценарии IoC мы бы вместо этого сделали что-то вроде этого:
В первом примере кода мы создаем экземпляр SpellChecker( this.checker = new SpellChecker();), что означает, что TextEditor класс напрямую зависит от SpellChecker класса.
Во втором примере кода мы создаем абстракцию, имея SpellCheckerкласс зависимости в TextEditorсигнатуре конструктора (не инициализируя зависимость в классе). Это позволяет нам вызвать зависимость, а затем передать ее классу TextEditor следующим образом:
Теперь клиент, создающий TextEditor класс, должен контролировать, какую SpellChecker реализацию использовать, потому что мы внедряем зависимость в TextEditor подпись.
Инверсия управления - это более общая концепция, а внедрение зависимостей - это конкретный шаблон проектирования.
Внедрение зависимости обычно означает передачу зависимого объекта в качестве параметра методу, а не создание методом зависимого объекта. Это очень полезный метод для тестирования, поскольку он позволяет имитировать или устранять зависимости.
На практике это означает, что метод не имеет прямой зависимости от конкретной реализации. Любая реализация, отвечающая требованиям, может быть передана в качестве параметра.
Зависимости могут быть введены в объекты любыми способами (такими как внедрение конструктора или установщика). Для этого можно даже использовать специализированные фреймворки внедрения зависимостей (например, Spring), но они определенно не требуются. Вам не нужны эти фреймворки для внедрения зависимостей. Создание и передача объектов (зависимостей) явным образом - это такая же хорошая инъекция, как и инъекция фреймворка.
Как концепция, инверсия управления не была полностью новой, когда Стеффано популяризировал ее в Apache в 1998 году. О некоторых ее частях раньше говорили как о принципе инверсии зависимостей (Боб Мартин) и «голливудском принципе» (не звоните нам, мы позвоним вам), а термин обрезанный появляется с 1996 года.
Банда четырех, Паттерны дизайна , 1994 «Голливудский паттерн» (не звоните нам, мы назовем вас) в качестве точки обсуждения паттерна «Шаблон».
Роберт К. Мартин, «Инверсия зависимостей» в публикации на comp.lang.c ++, август 1994: Метрики качества проектирования OO: анализ зависимостей ?
Роберт К. Мартин: «Принцип инверсии зависимостей» в публикации на comp.lang.c ++, июнь 1995 г .: Принципы OOD с последующей публикацией до июля 1995 г.
Роберт С. Мартин, Принцип инверсии зависимостей, В: C ++ Report, Vol. 8 мая 1996 г. См. .
Майкл Маттессон, 1996, Объектно-ориентированные фреймворки: обзор методологических вопросов «инверсия управления», используемая попутно.
Брайан Фут и Джозеф Йодер, июнь 1998 года. Большой шар грязи . Не столько на IoC, сколько на обстановке.
Ральф Э. Джонсон и Брайан Фут, июнь 1998 г., Проектирование многоразовых классов «инверсия управления» используется попутно.
Все подходы, основанные на инверсии управления, страдают от следующих двух недостатков :
неявный вызов - это термин, используемый некоторыми авторами для обозначения стиля архитектуры программного обеспечения, в котором система структурирована вокруг обработки событий с использованием формы обратного вызова . Это тесно связано с инверсией контроля и тем, что неофициально известно как принцип Голливуда .
Идея неявного вызова заключается в том, что вместо прямого вызова процедуры компонент может объявить (или передать) одно или несколько событий. Другие компоненты в системе могут регистрировать интерес к событию, связывая процедуру с событием. Когда событие объявляется, система сама вызывает все процедуры, которые были зарегистрированы для этого события. Таким образом, объявление о событии неявно вызывает вызов процедур в других модулях.
- «Введение в архитектуру программного обеспечения» , , Дэвид Гарлан и Мэри Шоу
Неявный вызов - это основная техника, лежащая в основе шаблона наблюдателя .
«Инверсия управления» - это способ разработки системы, в которой все модули рассматриваются как абстрактные объекты.
И «Внедрение зависимостей» - это реализация, в которой конкретное отношение между различными модулями определяется во время выполнения.
Хотя эти концепции можно использовать и предоставлять преимущества независимо, вместе они позволяют писать гораздо более гибкий, повторно используемый и тестируемый код. Как таковые, они являются важными концепциями при разработке объектно-ориентированных решений.
Представленные результаты и исследования подтверждают, что применение искусственного интеллекта в области инверсия управления имеет потенциал для революции в различных связанных с данной темой сферах. Надеюсь, что теперь ты понял что такое инверсия управления, inversion of control, ioc , инъекция зависимости , неявный вызов и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Объектно-ориентированное программирование ООП
Комментарии
Оставить комментарий
Объектно-ориентированное программирование ООП
Термины: Объектно-ориентированное программирование ООП