Что такое АОП, инжекция зависимостей и инверсия контроля на простом английском языке

Ответ 1

Я понимаю ваше замешательство, и мне потребовалось некоторое время, чтобы понять, как эти понятия связаны друг с другом. Итак, вот мое (как-то личное) объяснение всего этого:

1. Инверсия управления

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

myDependency.doThis();

с

myDependency.onEventX += doThis();

В последнем случае нет прямого вызова, которое более гибко. В его общем виде инверсия управления связана с шаблоном наблюдателя, событиями или обратными вызовами.

2. Инверсия зависимостей

Инверсия зависимостей - другой принцип проектирования. Грубо говоря, в нем говорится, что абстракция более высокого уровня не должна зависеть непосредственно от абстракций более низкого уровня; это действительно приводит к тому, что абстракция более высокого уровня не может быть повторно использована без абстракций более низкого уровня.

 class MyHighLevelClass {
     MyLowLevelClass dep = new MyLowLeverClass();
 }

 class App {
     void main() {  new HighLevelClass().doStuff(); }
 }

Здесь MyHighLevelClass не может компилироваться без доступа к MyLowLevelClass. Чтобы разбить эту связь, нам нужно отбросить класс низкого уровня с помощью интерфейса и удалить прямую инстанцирование.

class MyLowLevelClass implements MyUsefulAbstraction { ... }

class MyHighLevelClass {

    MyUsefulAbstraction dep;

    MyHighLevelClass( MyUsefulAbstraction dep ) {
        this.dep = dep;
    }
}

class App {
     void main() {  new HighLevelClass( new LowLevelClass() ).doStuff(); }
 }

Обратите внимание, что вам не нужно ничего особенного, как контейнер, для обеспечения инверсии зависимостей, что является принципом. Хорошее чтение Принцип инверсии зависимостей от дяди Боба.

3. Зависимость впрыска

Теперь идет инъекция зависимостей. Мне dependency injection = IoC + dependency inversion:

• Зависимости
• предоставляются снаружи, поэтому мы применяем принцип инверсии зависимостей
• контейнер устанавливает зависимости (а не мы), поэтому мы говорим об инверсии управления

В приведенном выше примере, инъекция зависимостей может быть выполнена, если контейнер используется для создания объектов и автоматически вводит зависимость в конструкторе (мы часто говорим о контейнере DI):

 class App {
     void main() {  DI.getHighLevelObject().doStuff(); }
 }

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

4. АОП

Строго говоря, АОП имеет мало общего с 3 предыдущими пунктами. семантическая бумага на AOP является очень обобщенной и представляет собой идею сплетения различных источников (возможно, выраженных на разных языках) для создания рабочего программного обеспечения.

Я больше не буду расширять AOP. Важно то, что инъекция зависимостей и АОП действительно эффективно сочетаются друг с другом, потому что они очень легко переплетаются. Если контейнер IoC и инъекция зависимостей используются для абстрагирования создания объектов, контейнер IoC можно легко использовать для сглаживания аспектов перед инъекцией зависимостей. В противном случае это потребовало бы специальной компиляции или специального ClassLoader.

Надеюсь, что это поможет.

Ответ 2

Инъекционная инъекция была очень хорошо объяснена в Как объяснить инъекцию зависимостей 5-летнему?:

Когда вы идете и получаете вещи из холодильник для себя, вы можете вызвать проблемы. Вы можете оставить дверь открыта, вы можете получить что-то Мама или папа не хочет, чтобы ты иметь. Вы даже можете найти то, чего у нас нет или что истек.

Что вы должны делать, это указать нужно: "Мне нужно что-нибудь выпить обед", а затем мы обязательно есть что-то, когда вы садитесь есть.

AOP - Аспектно ориентированное программирование - в основном означает, что источник, который вы пишете, модифицируется другим кодом, основанным на правилах, расположенных в ELSEWHERE. Это означает, что вы можете, например, скажем, "в качестве первой строки каждого метода я хочу" log.debug "(" метод ввода() ") в центральном месте, и каждый метод, который вы компилируете с этим правилом, будет включать эту строку. аспект" - это имя поиска кода другими способами, чем просто с первой строки источника до последнего.

Инверсия управления в основном означает, что у вас нет центральной части кода, которая управляет всем (например, гигантский переключатель в main()), но имеет много фрагментов кода, которые "почему-то" вызываются. Тема обсуждается в Википедии: http://en.wikipedia.org/wiki/Inversion_of_control

Ответ 3

Эти три - все разные концепции, но все они хорошо работают вместе, поэтому приложения Spring часто используют все это сразу. Я приведу вам пример.

Скажем, что у нас есть веб-приложение, которое может делать много разных вещей. Мы могли бы создать это приложение разными способами, но одним из способов является создание класса, который отвечает за выполнение каждой из этих вещей. Нам нужно вызывать и создавать эти классы откуда-то. Один из вариантов заключается в том, чтобы иметь большой основной класс, который создает одну из этих служб, открывает сокет и передает вызовы этим службам по мере их поступления. К сожалению, мы ушли и создали себе класс богов, который имеет способ слишком много логики и слишком много знает о том, как все в нашей программе работает. Если мы что-то изменим о нашей программе, нам, вероятно, понадобится изменить этот класс.

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

Способ обойти это - использовать инверсию управления. Мы говорим: "Хорошо, это классы обслуживания, кто их ставит, не я". Обычно каждый определяет интерфейс, например, LoginService или BillingService. В этом интерфейсе может быть более одной реализации, но ваше приложение не заботится. Он просто знает, что он может запросить определенный сервис или услугу с определенным именем, и он получит что-то хорошее назад.

Включение зависимости позволяет нам соединять все наши части litle вместе. Классы имеют доступные поля, аргументы конструктора или методы setter, которые являются ссылками на другие компоненты, которые им нужно получить. Это упрощает модульное тестирование. Вы можете создать объект, находящийся под тестированием, наложить на него ложную или заглушку, а затем проверить, что объект ведет себя корректно изолированно.

Теперь наше реальное приложение представляет собой сложный кусок штук, которые все должны быть связаны между собой именно так. Есть много способов сделать это, в том числе разрешить приложению делать догадки ( "этот класс хочет, чтобы UserService, есть только один класс, за который я отвечаю за то, что реализует UserService" ), или тщательно объясняя, как они объединяются в XML или Java. Spring, по своей сути, является сервисом, который заботится о том, чтобы объединить эти классы вместе.

Теперь мы попадаем в АОП. Скажем, у нас есть все эти классы, которые связаны друг с другом сложными способами. Есть несколько сквозных проблем, которые мы, возможно, захотим описать очень универсальными способами. Например, возможно, вы хотели бы начать транзакцию базы данных всякий раз, когда вы вызываете какую-либо службу, и совершите транзакцию, пока служба не генерирует исключение. Оказывается, что Spring находится в уникальном положении для выполнения такой задачи. Spring может создавать прокси-классы "на лету", которые реализуют любой интерфейс, который вам нужен, и он может обернуть ваш класс в его прокси. Теперь, IoC и инъекции зависимостей, конечно же, не нужны, чтобы делать аспектно-ориентированное программирование, но это чрезвычайно удобный способ выполнить это.

Ответ 4

Позвольте мне рассказать вам несколько слов об АОП, надеюсь, что это упростит понимание. Самым основополагающим принципом АОП является поиск общих задач/аспектов, которые возвращаются в многие места в коде и не принадлежат к конкретовому бизнесу кода. Например писать для входа в каждый вход любой функции или когда объект создается wrapp it, или отправлять электронную почту администратору при вызове определенной функции. Таким образом, вместо того, чтобы программисты будут обрабатывать этот аспект без businuss, мы берем его от них и мы управляем этими аспектами. Что все основные АОП на 1 ноге....

Ответ 5

Простое сравнение из Spring в действии:

В то время как DI помогает отделить ваше приложение объектов друг от друга, АОП помогает разделить межсекторальные проблемы с объекты, на которые они воздействуют.

Ответ 6

Разница между Injection Dependency и Inversion of Control очень хорошо объясняется в

http://martinfowler.com/articles/dipInTheWild.html

( "Вы имеете в виду ссылку на инверсию, правильно?" )

Резюме:

DI - это то, как один объект получает зависимость. Когда зависимость предоставляется снаружи, затем система использует DI.

IoC - это кто инициирует вызов. Если ваш код инициирует вызов, это не IoC, если контейнер/система/библиотека обращается к коду что вы предоставили его, это IoC.