Аспектно-ориентированное программирование по сравнению с объектно-ориентированным программированием

void set...(...) {
    :
    :
    Display.update();
}

, Если у Вас есть 3 метода установки, который не является проблемой. Если Вы имеете 200 (гипотетический), это возвращается к реальности болезненное для добавления этого везде. Также каждый раз, когда Вы добавляете новый метод установки, несомненно, не необходимо будет забыть добавлять это до конца, иначе Вы просто создали ошибку.

AOP решает это, не добавляя тонны кода, вместо этого Вы добавляете аспект:

after() : set() {
   Display.update();
}

И вот именно! Вместо того, чтобы писать обновление кодируют себя, Вы просто говорите системе, что после набора () pointcut был достигнут, это должно выполнить этот код, и это выполнит этот код. Никакая потребность обновить 200 методов, никакая потребность удостовериться Вы не забываете добавлять этот код нового метода установки. Дополнительно Вам просто нужен pointcut:

pointcut set() : execution(* set*(*) ) && this(MyGraphicsClass) && within(com.company.*);

, Что это означает? Это означает, называют ли метод "набором*" (*, означает, что любое имя могло бы следовать, после того, как установлено), независимо от того, что метод возвращает (первая звездочка) или какие параметры это берет (третья звездочка) , и это - метод MyGraphicsClass и , этот класс является частью пакета "com.company.* ", тогда это - набор () pointcut. И наш первый код говорит" после выполнение любого метода, который является набором pointcut, выполните следующий код".

Видят, как AOP изящно решает проблему здесь? На самом деле все описанное здесь может быть сделано во время компиляции. Препроцессор AOP может просто изменить Ваш источник (например, добавляющий Display.update () до конца каждого метода набора-pointcut) прежде даже скомпилировать сам класс.

Однако этот пример также показывает одну из больших оборотных сторон AOP. AOP на самом деле делает что-то, что многие программисты рассматривают" Антишаблон ". Точный шаблон называют" Действие на расстоянии ".

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

Как новичок к проекту, я мог бы просто считать код любого метода установки и считать поврежденным, поскольку это, кажется, не обновляет дисплей. Я не делаю , видят , просто смотря на код метода установки, что после того, как он выполняется, некоторый другой код будет "волшебно" выполнен для обновления дисплея. Я считаю это серьезной оборотной стороной! Путем внесения изменений в метод могли бы быть представлены странные ошибки. Далее понимая поток кода кода, где определенные вещи, кажется, работают правильно, но не очевидны (поскольку я сказал, они просто волшебно работают... так или иначе), действительно твердо.

Обновление

Просто для уточнения, что: у Некоторых людей могло бы быть впечатление, я говорю, что AOP - что-то плохо и не должен использоваться. Это не то, что я говорю! AOP является на самом деле замечательной особенностью. Я просто говорю, "Используют его тщательно". AOP только вызовет проблемы при спутывании нормального кода и AOP для того же Аспект . В примере выше, у нас есть Аспект обновления значений графического объекта и рисования обновленного объекта. Это - на самом деле единственный аспект. При кодировании половины из него как нормальный код и другая половина из него, поскольку аспект - то, что добавляет проблему.

при использовании AOP для совершенно другого аспекта, например, для входа Вы не столкнетесь с проблемой антишаблона. В этом случае новичок к проекту мог бы задаться вопросом, "Где делают все эти сообщения журнала прибывают из? Я не вижу, что любой журнал производит в коде", но это не огромная проблема. Изменения, которые он вносит в логику программы, едва повредят средство журнала, и изменения, внесенные в средство журнала, едва повредят его логику программы - эти аспекты полностью разделяются. Используя AOP для входа имеет преимущество, которое Ваш код программы может полностью сконцентрировать на выполнении вообще, это должно сделать, и у Вас все еще может быть сложный вход, не имея Вашего кода, загромождаемого сотнями сообщений журнала везде. Также, когда новый код представлен, волшебно зарегистрируйтесь, сообщения появятся в нужное время с правильным содержанием. Программист новичка не мог бы понять, почему они там или куда они произошли из, но так как они зарегистрируют "правильную вещь" в "правильное время", он может просто счастливо принять то, что они там и движение к чему-то еще.

, Таким образом, хорошее использование AOP в моем примере должно было бы всегда регистрироваться, если какое-либо значение было обновлено через метод установки. Это не создаст антишаблон и почти никогда не будет причиной никакой проблемы.

можно было бы сказать, если можно легко злоупотребить AOP для создания такого количества проблем, это - плохая идея использовать все это. Однако, какой технологией нельзя злоупотребить? Можно злоупотребить скрытием данных, можно злоупотребить наследованием. В значительной степени каждой полезной технологией программирования можно злоупотребить. Считайте язык программирования столь ограниченным, что он только содержит функции, которыми нельзя злоупотребить; язык, где функции могут только быть использованы, поскольку они были первоначально предназначены, чтобы использоваться. Такой язык был бы так ограничен, что спорно, может ли это даже использоваться для программирования реального мира.