从Design Pattern浅谈AOP

从GoF至今，随着不少大师级人物的的书籍、厂商和许多爱好者的追捧，Design Pattern这个词已是越来越被每个程序员挂在口上了。不说有多少人真正理解Design Pattern的本质，但至少大家都在努力的学习、研究和尝试，并能融入大家的日常开发，也总算是一片欣欣向荣之像。 

不过，终究Design Pattern也用了那么多年才像现在这般深入人心，AOP虽然学术上提出也不晚，但是从AspectJ开始有一些实际的应用至今，毕竟时间尚短，AOP要想发展到Design Pattern现在这种被了解和应用的程度，难免还是需要些时日的，需要更多更好的AOP工具甚至是编程语言的支持，也需要更多开发者像Design Pattern一样来认识和思考AOP的本质。

这里把AOP和Design Pattern放在一起比较，因为始终觉得AOP和Design Pattern处于相当的地位，他们能够起到的对软件开发的改善作用也是相当的。说“相当”并不是说“相等”，实际上，如果说Design Pattern是对编写更优雅、高效的OO代码的指导，那么AOP则可算是二进制级别的“Design Pattern”（基于DynamicProxy的所谓AOP实现，我认为是一种取巧的、有颇多限制的AOP实现方案，不能说这种方案没有操纵二进制代码，就说AOP是直接侵入源代码的）----也就是AOP中所谓的将Cross-cutting Concerns分离成Aspects的设计思想，他不像Design Pattern那样直接规范和侵入具体的源代码的修改，而是在二进制的级别进行模块甚至是代码块的组装，这种组装和Design Pattern的模块组装最大的不同还在于它是不必依赖于接口（Interface）的，也因此，它的灵活性肯定更大，性能的损失更小，当然也会带来一些新问题，比如调试。 

玩新技术，可意追求时髦，应用新技术则必须要先了解它的本质。一方面由于支持工具和学习资源的稀少，另一方面由于接受AOP二进制级别分离Aspect的新的设计思想和传统软件设计方法的不同，要了解AOP的本质，一定程度上不像了解Design Pattern那样直观和容易。毕竟，Design Pattern从表现形式上来说，还是本来那些OO元素，本质上没有增加什么新的物理概念，只是一些经验指导的汇集，所以，有人可以随便拿出一段OO代码，说这是XXX Pattern，这是KKK Pattern的叫嚣。而应用AOP，即使是错误的应用AOP，也必须接受新的理论概念和设计思想。

怎样基于AOP的理论进行设计和开发呢？前人已经有不少成文成书的经验甚至实践，且不说这些是不是最佳的经验和实践，毕竟都只能算是探索阶段的研究，作为读者，我们要时刻保持一份质疑的心态来面对。像“怎样基于AOP的理论进行设计和开发”这样的问题，也该由我们自己在了解AOP本质的基础上来判断。就像本文的观点，也只是Teddy个人的看法和认识，不至于完全是瞎说，但可能很多地方受我的经验和已有认识的局限，所以我更希望看到的是诚恳的批评指教而不是盲目的支持或泼骂。 

[More about AOP]