还在《程序员》做编辑的时候，我曾经主持过一次关于AOP的技术专题。凭着传说中的“敏锐的技术嗅觉”（呵呵，听起来像狗鼻子），我感觉AOP会是一个很有用的东西，尽管当时还不知道具体有什么用。（拉句废话：《程序员》正在招聘技术编辑，如果你认为自己吹牛的本事胜过编程，又善于胡思乱想——就像我这样，我会建议你去尝试一下这个职位。）
我的朋友恶魔曾经多次说起“GP与‘面向事件编程’”这个话题。按照我的理解，所谓“事件编程”主要解决的是一个正交分解的问题，而GP恰好是一个提供正交分解的范式。最近，国外J2EE社群经常在讨论AOP，似乎他们认为AOP提供的正交分解能力很适合解决诸如业务流之类EAI经常碰到的问题……又开始漫天吹牛皮了。放下鬼扯的东西，我想看看AOP究竟可以做什么。
AOP可以用于Java程序的使用限制。在发布之前，先用AspectJ给每个类织入身份验证的逻辑，这样要破解就会困难得多。关于AOP如何用于身份验证和授权，在这里有一篇文章：http://www.theserverside.com/resources/review/AspectJ/chapter10_AspectJ.zip
另一个令人遐想联翩的成果是Jan Hannemann和Gregor Kiczales得到的，他们用AOP实现了GOF的23个设计模式。对于其中的17个模式，他们成功地借助AspectJ去除了各参与者之间的代码级依赖。一般认为，设计模式在带来灵活性的同时也使代码变得复杂而难以阅读，“获得灵活性”的模式框架代码与“完成功能”的业务代码混淆在一起，容易使阅读者迷失方向。因此Jan Hannemann和Gregor Kiczales进行的这个实验是相当有意义的，它可能会大大提高普通程序员使用设计模式的积极性。甚至可以期望，设计模式由水平较高的程序员来实现，只须将其织入有需要的模块之中即可。
在http://www.cs.ubc.ca/~jan/AODPs/gof.zip可以下载他们用AOP实现GOF模式的代码示例。在编译运行这些示例之前，你需要首先安装JDK和AspectJ（http://www.aspectj.org）。他们在OOPSLA 2002大会上做了一个题为“Design Pattern Implementation in Java and AspectJ”的演讲，你可以在http://www.cs.ubc.ca/~jan/papers/oopsla2002/oopsla02-patterns.pdf看到这篇演讲的全文。
Joshua Kerievsky曾经写过一个名为“Refactoring to Patterns”的系列文章。他认为，在设计的前期引入模式很可能导致过度工程（over-engineering）。也许，今后模式社群可以考虑“refactoring to aspects”的思路：将设计模式抽取到一个aspect中，然后将其织入需要的模块。灵活性与代码的清晰，鱼与熊掌可以得兼？
Jan Hannemann和Gregor Kiczales的主页：http://www.cs.ubc.ca/~jan/AODPs/
AOP和AspectJ的信息：http://www.aspectj.org
《程序员》对AOP的介绍：http://www.csdn.net/magazine/old/200211.shtm
