Что случилось с аспектно-ориентированным программированием?

Ответ 1

В начале 2000-х годов было много шумихи, и произошло следующее: было много попыток создания аспектно-ориентированных фреймворков, и эти попытки объединились в два важных проекта в сфере Java: AspectJ и Spring АОП. AspectJ является полным, сложным, академичным, несколько перегруженным. Spring АОП покрывает 80% случаев использования с 20% сложности.

Если вы посмотрите на Google Trends для терминов "AspectJ, Spring AOP" , сравните с популярностью самой Java, вы будете что относительная популярность AspectJ несколько постоянна, но Spring AOP поднимается. Это означает, что люди используют АОП, но не хотят сложности AspectJ. Я думаю, что создатели AspectJ сделали много тактических ошибок; AspectJ всегда был исследовательским проектом и не был разработан "для масс".

В сфере .NET мы наблюдаем аналогичный интерес для АОП в начале 2000-х годов. В 2003 году, когда я начал исследования AOP, для .NET было полдюжины ткачей AOP. все шли по пути AspectJ, и все были на стадии младенчества. Ни один из этих проектов не сохранился. Основываясь на этом анализе, я построил PostSharp, который был разработан, чтобы охватить 80% случаев использования с 20% сложности, и все же был гораздо удобнее в использовании, чем Spring AOP. PostSharp теперь считается ведущим инструментом для .NET. PostSharp 2.0 основывается на 5-летней обратной связи и от отраслевого опыта AspectJ и приносит "готовую к работе" AOP (будущее будет судить, если это требование заслуживает). Помимо PostSharp, другими значимыми игроками являются Spring Framework для .NET и Windsor Castle, две DI-ориентированные структуры приложений, предоставляющие "также" аспекты (аспекты рассматриваются как зависимости, вводимые в построенные объекты). Поскольку эти технологии используют плетение во время работы, они имеют серьезные технические ограничения, поэтому практически они могут использоваться только в объектах обслуживания (для чего предназначены эти рамки приложения). Другим стартовым проектом в .NET является LinFu, который может также "аспект".

Чтобы быть коротким, пейзаж AOP претерпел некоторую консолидацию в последние годы и, вероятно, входит в фазу производительности: клиенты будут использовать его, потому что это действительно экономит деньги, а не потому, что это круто. Даже если это очень круто:).

О, и я забыл: у большинства серверов приложений есть встроенная поддержка AOP. Думая о JBoss, WebSphere и, в некоторой степени, WCF.

Ответ 2

Это происходит с каждой "следующей большой вещью". Много шумихи, сопровождаемое медленным снижением использования модного слова. Но, несмотря на то, что модные слова исчезают и, в конце концов, исчезают, любые хорошие идеи, стоящие за ними, склонны придерживаться, чтобы впитаться в мейнстрим.

[ Изменить]. Хорошо, пример для тех, кто думает, что я что-то "избиваю" или утверждаю, что аспектное программирование исчезнет. В свое время следующая большая вещь была структурированным программированием. Из этого возникло объектно-ориентированное программирование, и теперь никто не говорит о том, чтобы делать "структурированное программирование". Но во многих отношениях мы все еще используем его лучшие идеи, потому что ООП принял их, улучшил их и добавил еще новые идеи.

Ответ 3

AOP на самом деле действительно блестящий, проблема заключается в том, что ни один из существующих языков не поддерживает его. У Sure есть атрибуты (которые работают только тогда, когда вы CODING вещь), а у Java есть "инъекция" (что создает беспорядок из среды исполнения), но в целом нет (основных) языков, которые действительно поддерживают его...

Итак, это вроде как "шаблон дизайна" (с безумно разными реализациями на всех разных языках), который, в конце концов, не так уж плох, я думаю;)

Ответ 4

Что касается некоторых проектов, мой собственный опыт в недавнем проекте - это слишком легко злоупотреблять:(!!! Что запустило хороший способ настройки отладки, синхронизации и некоторого расширения управления транзакциями, он быстро получил повреждение самый странный и сложный код для понимания и отладки, который я видел через некоторое время.

просто чтобы разбить бит на стороне отладки/диагностики, трассировки стека, сгенерированные кодом AOP, много раз скрывают до неузнаваемости фактическое место, где произошло исключение.

Ответ 5

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

Также на этом этапе проще упростить многоядерное программирование, и я не думаю, что аспектно-ориентированное программирование поможет в этом.

Вы также можете найти много контента на Принятие рисков.