AOP-面向方面的程序设计

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流程难以跟踪的本质原因。