Аспектно-ориентированное программирование

В статье рассматривается новая парадигма программирования – аспектно-ориентированное программирование. Данная парадигма возникла сравнительно недавно и пока только определены её основные рамки. Читатель может ознакомиться с основными понятиями и получить представление об АОП, как о технике программирования. Выяснить в чём заключается различие между объектно-ориентированным программированием и аспектно-ориентированным программированием, какая из техник является более эффективной.

В процессе эволюции человечество постоянно пытается решить проблему «Как организовать максимальный выход продукта при минимальных затратах?». Причём эту проблему человек пытается решить во всех областях своей деятельности, будь то производство хлебобулочных изделий или же разработка очередного спутника NASA. То же самое можно сказать и о программировании.
Всю эволюцию программирования можно представить, как процесс, направленный на снижение программного кода и увеличение эффективности его использования. В эпоху зарождения программирования программы представляли собой набор машинных команд. Основное занятие программистов заключалось в составлении машинных инструкций. Но компьютерная индустрия развивается динамично, растут задачи и требования. Как результат появились языки программирования более высокого уровня, позволяющие отойти от машинного кода, абстрагироваться и более визуально решать поставленные проблемы. Появились структурированные языки, здесь уже пришлось думать о том, как разбить большое задание, разработку общего поведения и интерфейса для взаимосвязанных концепций и изменение обычного поведения более специализированных компонентов без обращения к реализации базовой концепции. Таким образом, на данном этапе появилась возможность избежать множества ошибок, сопутствующих структурному и модульному программированию, внести большую ясность при разработке программного обеспечения. Как вполне естественный результат развития и совершенствования техники ООП возникло компонентное программирование, позволившее более эффективную организацию данных.
Так наблюдая за развитием программирования можно сделать следующие выводы: чем дальше идет эволюция программирования, тем большему обобщению подвергаются его составляющие. Сначала организовали набор машинных инструкций в единые блоки, далее эти блоки совместили в одном модуле. Всё, очевидно, чем дальше идет развитие, тем больше уровень комплексности и абстракции, тем все более становится скрытным базовая реализация тех компонентов программирования, с которыми мы работаем.
Как мы уже говорили, сложность программного обеспечения и методологий программирования постоянно возрастает, также постоянно предпринимаются попытки разорвать этот замкнутый круг. Xerox PARC, IBM и Microsoft готовят для индустрии ПО новую парадигму программирования. Она называется аспектно-ориентированное программирование (АОП, aspect-oriented programming) и призвана прийти на смену объектно-ориентированному (ООП, object-oriented programming) и компонентному (component-based programming) программированию. Основными идеологами нового программирования являются Грегор Кишалес (Xerox PARC) и Чарльз Саймони, бывший ведущий архитектор Microsoft.
Аспектно-ориентированное программирование (АОП) (aspect-oriented programming, AOP) — парадигма, изобретенная в Xerox PARC в 90-х гг. и позволяющая разработчику четко разделять задачи, которые не следует запутывать в клубок, например математические операции и обработку исключений. АОП имеет ряд преимуществ. Во-первых, он повышает производительность, так как операции выполняются быстрее. Во-вторых, программисты тратят меньше времени на переписывание одного и того же кода. В целом, АОП обеспечивает более качественную инкапсуляцию различных процедур и облегчает взаимодействие с кодом, написанным на других языках программирования.
Состояние развития АОП похоже на состояние ООП 20 лет назад, данная методика находится на стадии исследований, ещё только определены её рамки и основные понятия. Парадигма аспектно-ориентированного программирования (АОП, aspect-oriented programming) призвана прийти на смену объектно-ориентированному (ООП, object-oriented programming) и компонентному (component-based programming) программированию. По оценкам специалистов, около 70% времени в проектах тратится на сопровождение и внесение изменений в готовый программный код. Вот почему столь важной в ближайшей перспективе становится роль АОП и подобных трансформационных подходов.
Направление развития программирования очевидно. Никому не хочется тратить время и усилия на изменение готовых разработок. Также остро стоят проблемы «повторного использования кода» и «пересекающегося кода» (code crosscutting). Проблема пересекающегося кода состоит в том, что при реализации решения задачи встречается программный код, по сути выполняющий одну и туже функцию в разных частях программы. Что выражается в: плохой трассировке, низкой продуктивности, плохом качестве программного кода, более трудной модификации и низкой эффективности повторного использования кода Проблема повторного использования кода начала решаться с появления программирования, но нашла своё решение при появлении ООП. До этого этапа можно отметить значительный вклад в решение этой задачи модульного программирования, но здесь можно было использовать модули, если между разработчиками программ были оговорены правила их использования и применения. С появлением объектно-ориентированного программирования стало возможным организовать относительно слабосвязанную систему, компоненты которой менее зависят друг от друга, как это было ранее, кроме того, разработанные объекты стало возможным применять в программе, не задумываясь о том, кто их написал. Такое положение сейчас уже вполне естественно, каждый человек, хоть немного знакомый с программированием, сейчас без проблем может написать объектно-ориентированную программу (используя, например, язык программирования Delphi), не задумываясь о том, что за компонентом, который он выбрал, стоит не одна сотня строк программного кода. Как мы уже говорили, всё очевидно. Никто не желает выполнять лишнюю работу, под словами «лень-двигатель прогресса» проходит вся эволюция человека, это касается всех сфер его деятельности, в том числе и программирования.

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

Такие языки программирования как, например, C++, VB, Delphi и т.п. ориентированы, прежде всего, на решение первой задачи. Код компонента представляется в виде класса, то есть он хорошо локализован и, следовательно, его легко просматривать, изучать, модифицировать, повторно использовать. С другой стороны, при программировании процессов, в которые вовлечены различные объекты, мы получаем код, в котором элементы, связанные с поддержкой такого процесса, распределены по коду всей системы. Эти элементы встречаются в коде множества классов, их совокупность в целом не локализована в обозримом сегменте кода. В результате мы сталкиваемся с проблемой «запутанного» и «пересекающегося» кода (code tangling и code crosscutting).
АОП создает систему, используя слабосвязанные модульные разработки пересекающихся моделей. Модульная часть в аспектно-ориентированном программировании называется аспектом, тогда как общая модель в ООП носит название - класс.
Аспект (ключевое понятие новой парадигмы) представляет собой языковую концепцию, схожую с классом, но только более высокого уровня абстракции. Аспекты могут затрагивать многие классы и используют так называемые точки вставки (insertion points) для реализации регулярных действий (например, связанных с безопасностью, обработкой ошибок и т. п.), которые обычно «размазаны» по всему тексту программы. АОП отличается от ООП, тем, как адресуются пересекающиеся модели. В АОП реализация каждой модели не подозревает о существовании другой, пересекающей ее структуру. Вспомним, что при использовании техники ООП создаётся система из объектов, связь между которыми осуществляется через действия.
Технология АОП позволяет выделить многократно повторяющийся код в простые блоки, называющиеся аспектами. Аспекты инкапсулируют множество классов в один модуль, к которому можно осуществлять обращение из любого места программного кода. Требования аспектного программирования заключаются в том, что при разработке аспект рассматривают как модель, пересекающую структуру другой модели.
В АОП каждый аспект может быть выражен в единичной форме, и далее они автоматически комбинируются в исполняемый код с помощью так называемого сборщика (aspect weaver). В результате каждый аспект представляет реализацию некоторого числа модулей или объектов, увеличивая возможности повторного использования кода. По сравнению с традиционным подходом после этапа кодирования компонентов и аспектов на соответствующих языках выполняется автоматическое построение оптимизированного для выполнения (но не для просмотра и модификации) кода. Сборщик аспектов может автоматически вставить точку входа для любого набора операций, что позволяет разделить пересекающийся код на уровне исходного кода.

Таким образом, АОП позволяет снизить объём кода программы и увеличить эффективность повторного использования кода.
В рамках АОП утверждается, что никакая технология проектирования не поможет решить данную проблему, если оставаться в рамках языка, ориентированного только на разработку компонентов. Для программирования сервисов, обеспечивающих взаимодействие объектов, нужны специальные средства, возможно специальные языки.
Понятие аспект можно определить так: «некоторая модель является аспектом другой модели, если она пересекает (crosscuts) ее структуру». Иными словами понятие аспекта относительно. Если, например, в качестве модели некоторой системы мы рассматриваем совокупность компонентов, представляющих такие сущности как вкладчик, счет, банк, то аспектами являются сервисы, обеспечивающие синхронизацию доступа к счету, распределенные транзакции, безопасность. То есть автоматически выполняемые сервисы, обеспечивающие слаженную, надежную, безопасную работу компонентов.

Преимущества АОП

Как мы уже говорили АОП помогает решить проблемы, касающиеся запутанного кода (code tangling) и разбросанного кода (code scattering). Специфичные преимущества АОП таковы:
Модульная реализация пересекающихся моделей: АОП адресует каждую модель отдельно, с минимальной связностью, что отражается в модульной реализации, даже если присутствует перекрещивание моделей. Такая реализация снижает дублирование кода. Так как каждая проблема реализуется отдельно, это позволяет снизить размер кода. В дальнейшем модульная реализация приводит к более легкому пониманию и сопровождению системы.
Системы легки для развития: Так как аспектные модули могут не знать о пересечении проблем, то легко можно добавить функциональность путем создания нового аспекта. В дальнейшем, при добавлении нового аспекта в систему, существующие аспекты пересекают его структуру, помогая создавать гармоничную эволюцию.
Более поздняя связь с проектным решением: Вспомним проблему разработчиков решить проблему, придерживаясь ее рамок, или расширить ее границы. С АОП разработчики могут задержаться с разработкой проекта для будущих требований, так как они могут быть реализованы в будущем как отдельные классы.
Более широкие возможности повторного использования: Так как АОП решение - это аспекты, как отдельные модули, каждый отдельный модуль слабо связан с остальными. Например, вы можете использовать модуль взаимодействия с базой данных в отдельном аспекте регистрационного механизма с различными требованиями регистрации. В общем, слабосвязанные реализации являются ключом к широкому повторному использования кода. АОП представляет более слабосвязанные решения, чем ООП.

Нужно ли нам АОП? Устраняет ли АОП проектировочные недостатки? В АОП каждая реализация модели означает тот факт, что она пересекает структуру другой модели, которая может не подозревать о ее существовании. Такая «забывчивость» и отличает АОП от технологий ООП. В АОП поток формируется из пересекающихся моделей в главную модель, в то время, как в ООП поток работает в противоположном направлении. Заметим, тем не менее, что АОП и ООП неплохо уживаются рядом. Например, можно представить смешанный класс, как модель, используя как АОП, так и ООП, только на уровне АОП это будет более удобно. В любом случае, реализация пересекающейся модели смешанного класса не нуждается в том, чтобы знать, каким образом она была реализована. Например, в одном случае вы можете использовать интерфейс регистратора событий, как смешанный класс, в другом как аспект. Мы только можем говорить об эволюции ООП в АОП.
Пока АОП в качестве АОП еще только новая идея, элементы которой используются в уже существующих технологиях.
АОП можно поддерживать в рамках уже существующих языков. Так, в частности, исследовательский центр Xerox PARC разработал систему AspectJ (www.aspectj.org), поддерживающую АОП в рамках языка Java. В ноябре 2002 г. вышел новый релиз AspectJ 1.1. Этот пакет встраивается в такие системы разработки, как Eclipse, Sun ONE Studio (http://forte.sun.com/ffj/articles/aspectJ.html) и Borland JBuilder. Другой исследовательский центр — IBM Research — выпустил альфа-версию HyperJ (http://www.alphaworks.ibm.com/tech/hyperj) и готовит к марту 2003 г. выпуск системы Cosmos (http://www.research.ibm.com/AEM/mdsoc.html) с гипертекстовой поддержкой требований и диаграмм. Cosmos является развитием MDSOC, которая, в свою очередь, опирается на идеи субъектно-ориентированного программирования (http://www.research.ibm.com/sop/). Помимо Java новая идеология поддерживается и в других языках, таких как Си, Си++, Squeak/Smalltalk, Perl, Python, Ruby (http://aosd.net/tools.html). Пока интерес к новой парадигме проявляют несколько сот экспертов из General Electric, Hewlett-Packard, Siemens, Motorola, Oracle и Sony. Очевидно, что их число будет расти.
 
1-1 можно быстро Скачать WoW аддоны бесплатно для всех классов очень классно! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40