AOP-面向方面的程序设计

Aop：aspect oriented programming
oop: object oriented programming
AOP和OOP是两种不同的认识事物的角度,并不是说有了AOP就不要用OOP。Aop并不能取代oop，aop所要做的是以一种简洁和优雅的方式解决传统的oop问题。转述一段aspectj in action中的原文。

AOP will replace OOP: False. Core concerns will continue to be implemented in OOP (or even procedural programming). AOP simply adds a few additional concepts to OOP, just as OOP adds to procedural programming. However, AOP will change the way we use OOP and procedural languages for implementing crosscutting concerns. A few currently used design patterns and idioms that specifically address the problems of crosscutting concerns will lose their importance. Further, crosscutting concerns will receive a lot less attention during the initial design phase.

关于aspect的中文翻译，个人感觉实在很别扭，不管是面向方面，面向切面，都感觉无法表达其精髓，oop是以事物对象为从发点来考虑问题的，它认为对象应该有特点（属性）和动作（方法）。但完成一件事务，需要一堆对象共同合作。而aop正是从业务逻辑（事务）的角度来看待问题的，它是对事务的封装，其精髓在于一个事务只关心本身的逻辑，而无需关注旁支末节。

aop有很多优点，在aspectj in action中讲的很透彻，呵呵，其实这也是一本老书了，03年的。不过万变不离其宗。这里个人总结一下 🙂
1、各个模块职责清晰，每个模块只需关心自个儿的核心业务，无需考虑其他交叉的业务逻辑，比如日志记录、业务授权检查、用户权限检查。这是一个非常了不起的功能啊，想像一下，无任是面向过程，面向对象，我们以往在实现核心业务逻辑时，不是都要写上一大堆相关的检查和记录吗（哪怕是调用已经封装好的方法）。当系统规模小时倒没什么感觉，一旦系统规模大起来了，这将是一个非常繁重的工作，而且业务逻辑也不清晰了。
2、高度的模块化，Aop提供了一种机制使得模块间的耦合度达到了最低的限度（AspectJ in action中这么说的）， 即使是表现交叉逻辑时，因为模块时分离的，它也避免的代码的混乱。这将使的系统变的简单和易于维护。
3、系统更易扩展，增加一个新的业务逻辑将变的更加容易。
可以在系统underdesign＆overdesign之间取得平衡，部分设计可以放到末期，而无需大到手脚；也可以放在前期，到后期将其移走，而不用破坏主程序。何其块哉！
4、剩下的3个优点：more code reuse,improve time to market,reduced cost of featur implementation ，文中说了很多，不过是老生话题，不转述了。

但任何好的东东必然有其不足的一面，aop也例外。
1、程序中的流程将变的难以跟踪，噢，这是一个非常令人头痛的事情，写核心业务的人有时候甚至不知道自己的程序里被加入了什么怪物，呵呵，不过个人认为这是个见怪不怪的事情，熟练了自然就行了。我们也不是第一次碰到这种情况了，从面向过程转到面向对象，多态的支持等等，不都有同样的故事嘛。随着IDE的支持，这将也不是问题。
2、AOP不能解决任何新的的问题，它只是把oop情况下的代码美容师而已。In fact, AOP requires a good design of core concerns and makes it easy to achieve an overall clean design goal.
3、aop是个好东西，但你必须有一个好的oop。个人认为，一个好的oop是一个好的aop的基础，一堆混乱的对象＆接口&实现，只会使代码变的更糟，而不是更优雅。
4、aop打破了封装，在面向对象的编程中，一个对象封装了其相应的方法＆属性，但aop的介入，打破的对象在控制流层面（包括系统层面）的封装。个人认为，这就是aop流程难以跟踪的本质原因。