Грегор Кикзалес рассказывает об эволюции и будущем АОП
Основоположник аспектно-ориентированного программирования (АОП) Грегор Кикзалес сегодня преподает в Университете Британской Колумбии (Ванкувер, Канада). Он был лидером в создании АОП в середине и конце 90-х годов прошлого века, работая в Исследовательском центре Xerox в Пало-Альто, который помог представить эту технологию мировому сообществу. Во время своей недавней встречи со старшим редактором eWeek Дэррилом Тафтом Грегор Кикзалес рассказал об истории и будущем АОП.
eWeek: Откуда пошло аспектно-ориентированное программирование? И что это такое?
Грегор Кикзалес: Если проследить эволюцию программирования от машинного кода к процедурным языкам типа Algol и Pascal и дальше к объектно-ориентированным языкам наподобие Smalltalk и Java, то можно увидеть, что ее лейтмотивом было стремление помочь архитекторам и программистам в структурировании сложных систем.
Ведь системы слишком велики, чтобы думать о них на микроуровне. АОП по существу – очередной этап в развитии механизмов структурирования. Сегодня понятно, что объекты не заменяют процедуры, а являются только способом создания механизма структурирования более высокого уровня. И аспекты тоже не заменяют объекты; они лишь предоставляют еще одну разновидность структурирования.
Если послушать про то, что люди делают с аспектами, то становится понятно, что реально они занимаются именно структурированием. Например, когда люди заявляют: “Я могу поставлять свою систему с шестью разными политиками регистрации”, — на самом деле они имеют в виду следующее: “Я смог так структурировать свою систему, чтобы регистрация стала автономным аспектом ее поведения. И поэтому могу предложить целых шесть вариантов”.
Таким образом, если мыслить в терминах структуры или модульности, то один и тот же тезис можно словесно выразить двумя разными способами. Реальная же альтернатива состоит вот в чем: “Представляет ли моя большая, гигантская система один громадный неразъемный узел, о котором можно думать не иначе, как об одном сложном узле? Или же моя огромная сложная система является коллекцией подкомпонентов и ряд крупных подкомпонентов, в свою очередь, распадается на более мелкие части? И я знаю, каким образом из нее можно изъять определенную часть и заменить новым компонентом, что несколько изменит поведение системы, однако заранее понятным образом”.
eWeek: А что такое аспект?
Г. К.: Аспект — это специфическая разновидность части, для которой применимо понятие перекрестного (cross-cutting) поведения. А под перекрестным поведением следует понимать то, что одновременно влияет на выполнение многих функций систем. Например, пусть у вас есть какое-то корпоративное Web-приложение и вы добавляете в структуру учетной записи новое поле. Понятно, что это новое поле добавится во все учетные записи. Это достаточно локальный эффект.
Но если вы говорите: “Я хочу усилить безопасность доступа ко всем частям всех учетных записей”, — это будет перекрестный эффект, затрагивающий в одинаковой мере целое множество вещей.
eWeek: Вернемся к началу разговора. Вы работали в команде, создававшей АОП?
Г. К.: Как часто бывает с подобного рода идеями, над АОП трудились разные группы из разных мест. Нашей группе в Исследовательском центре Xerox в Пало-Альто обычно приписывается заслуга кристаллизации простейшей версии АОП, однако к этому же пришли и другие люди, например группа Гарольда Осшера из IBM.
У нас в центре была группа — ее возглавляли я и Джон Лэмпинг, — пытавшаяся вникнуть в один вопрос. Нам хотелось иметь простые программы без ошибок, и мы обратили внимание на то, что при наличии перекрестных эффектов программы таковыми быть не могут, так как одна и та же вещь может себя проявлять в 22-х разных местах.
А если одна и та же вещь проявляется в 22-х разных местах, жди беды. Потому что либо вы можете забыть про еще одно, 23-е место, либо кто-то решит что-нибудь изменить, но внесет коррективы только в 21-м месте.
Мы в определенной мере сконцентрировались на понятии перекрестной структуры и создали язык, позволяющий поставить такие вещи под контроль.
eWeek: И вы при этом имели в виду конкретную платформу или среду? Вы ориентировались на Java?
Г. К.: Наша работа реально началась еще до Java. И когда стало понятно, что нужно делать, пришла пора создавать реально работающую версию. Как раз в этот момент на свет появилась Java, и мы решили, что она-то и будет самым подходящим выбором. Ведь для нее не имелось никакого унаследованного кода, и мы чувствовали, что благодаря этому люди будут более открыты для новых идей. Итак, примерно в 1998 г. мы начали создавать AspectJ, держа в голове Java, а потом AspectJ стал исходной точкой разработки целого аспектно-ориентированного проекта для Java. Однако мы уже понимали, что сама идея АОП этой платформой не ограничивается.
e Week: А когда вы вообще приступили к проекту АОП?
Г. К.: Это как считать, но думаю, что слово “аспектно-ориентированный” впервые появилось в нашем лексиконе в 1995—1996 гг. В принципе же мы занимаемся данной идеей примерно с 1986 г., тогда началась работа над рефлексией. Однако позже мы решили, что это слишком мощный инструмент для практического применения и чересчур сложный для большинства людей. Рефлексия позволяла делать всё то же самое, что и АОП. А проблема состояла в том, чтобы все это стало понятным для разработчиков.
eWeek: Вы не поясните смысл рефлексии?
Г. К.: Идея рефлексии состоит в том, что если у вас есть работающая система, то ей дозволяется выйти на метауровень и самостоятельно взглянуть на рабочую программу. Присмотревшись к этой программе, система может ее изменить, чтобы начать делать какие-то иные вещи. Это невероятно мощная идея. Благодаря рефлексии можно делать практически всё.
АОП — куда менее мощный инструмент. Например, вы не можете реально взглянуть на запускаемую программу. Вы можете только сказать: “При наличии перекрестных эффектов надо сделать так-то и так-то”. Следовательно, это значительно ослабленная версия исходной идеи. И связано это с тем, что использование рефлексии на практике по плечу только самым умным и опытным программистам.
eWeek: Вы здесь почувствовали крупные перспективы?
Г. К.: Да, с моей точки зрения, это была фантастическая удача. Такие проекты бывают раз в жизни. Что же касается практического выхода… Будет ли у нас через десяток лет AspectJ или языковая структура под названием “point-cut” — ничего определенного сказать не могу. Но идея “модуляризировать” всё, что связано с перекрестными эффектами, остается в силе.
eWeek: А кто в первую очередь мог бы использовать АОП?
Г. К.: Почти все разработчики корпоративных приложений могут руководствоваться идеей аспектно-ориентированного программирования. Без этого сложно работать в среде Spring или JBoss. Так что АОП — начальная ниша.
Эффект chasm-crossing [“Crossing the Chasm” — название книги Дж. А. Мура (1991 г.) о переходе высоких технологий с этапа их использования лишь энтузиастами на этап массового внедрения в практику. — Прим. ред.] с AspectJ пока не достигнут. Нельзя сказать, что этот язык взяли на вооружение все Java-программисты, однако к нему прибегают многие из высококвалифицированных Java-разработчиков. Кроме того, целый ряд Java-программистов хоть и не умеют пользоваться AspectJ, но пишут свой код, реально думая об аспектах. Chasm-crossing не произойдет до тех пор, пока не появится полноценный и поддерживаемый на всех уровнях новый язык, хотя есть и исследователи, работающие над аспектно-ориентированной виртуальной машиной. Когда AspectJ созреет до этого состояния, тогда и сможет осуществиться chasm-crossing.
eWeek: А как можно облегчить внедрение АОП? Трудно ли писать аспектно-ориентированные программы?
Г. К.: Здесь имеется ряд временных, но критических проблем с низкоуровневыми инструментами. Чтобы использовать AspectJ в реальной системе, необходимо разобраться в некоторых вопросах низкого уровня.
eWeek: Создатель Java Джеймс Гослинг как-то сказал мне, что, по его мнению, передать АОП в руки типичного Java-разработчика это всё равно, что разрешить пятилетнему ребенку играть с бритвенными лезвиями.
Г. К.: Я всё-таки думаю, что эта метафора неверна, потому что мы видели, что написание правильного аспектного кода при работе над реальной программой не так уж сложно.
Однако мотивы позиции Гослинга мне понятны. Если проводить сравнение с любым другим из существующих языков, то с Java сегодня имеет дело более широкий спектр программистов с разным уровнем способностей. Большинство пишущих на Visual Basic ведет разработки одинакового уровня сложности. Java же используют как исключительно высоко одаренные программисты, так и программисты более низких уровней квалификации. И это входило в замыслы создателей языка.
“Мы сконцентрировались на понятии перекрестной структуры и создали язык, позволяющий поставить эти эффекты под контроль”.
Вот почему у Гослинга бывают экстраординарные проблемы, когда он общается с публикой. Такие же особенные проблемы имеет и Sun Microsystems, когда компания думает о дальнейших перспективах развития Java.
Поскольку Гослинг старается заботиться обо всех категориях разработчиков, ему приходится быть консервативным. И мы пока не знаем, как научить АОП технически менее искушенную публику.
