理解AOP

我觉得面向对象很好地解决了软件系统中职责划分的问题.借助于面向对象,软件开发人员一般的,都可以将需求里的名词转换成系统中的对象,动词转换为对象里的方法.这样非常符合人的思维方式,非常自然.

但是,问题是某些需求却偏偏不是能用这样的”名词”和”动词”就能完美的描述出来的,假如这样的问题:需要对系统中的某些方法进行事务处理,这种需要事务代码散布在多个类中.面对这种需求,应该怎么办呢?最直接的办法就是:创建一个基类(接口)或者一个助手,将事务处理的功能放在其中,并让所有需要事务功能的类继承这个基类(接口)或者使用这个助手.加入这样的.需要修改的地方就会分散在多个文件中.这样大的修改量,无疑会增加出错的几率,并且加大系统维护的难度,如图:

                                     

因此,面向方面的编程(Aspect Oriented Programming,AOP)应运而生.AOP为开发者提供了一种描述横切关注点的机制,并能够自动将横切关注点织入到面向对象的软件系统中，从而实现了横切关注点的模块化.通过划分Aspect代码,横切关注点变得容易处理.开发者可以在编译时更改,插入或除去系统的Aspect,甚至重用系统的Aspect.” OOP只用于表示对象之间的泛化-特化(generalization-specialization)关系(通过继承来表现),而对象之间的横向关联则完全用AOP来表现. 这样,很多给对象之间横向关联增加灵活性的设计模式(例如Decorator等)将不再必要.”,如图:
                                      

Spring中的Ioc

想一想以前在使用工厂模式的时候,在最早的情况下,每个工厂可能都是一个Singleton,生成对象的代码被写死在了类里面.后来人们觉这样还是耦合程度太高,还不够灵活.所以把对象的类名写在一个XML文件里,这样一来.问题又来了,每个工厂都有自己的读取配置文件的代码,通过读取XML文件,或者通过读取Properties,工厂里充满了乱糟糟的和业务逻辑完全不相关的配置管理代码,维护起来很不方便,.而Spring通过”组件工厂”把这些都集成在了一起,用一个统一的BeanFactory来管理这些配置,而且提供了更高一级的抽象:ApplicationContext

Ioc好像很神奇的样子,其实原理和实现都很简单,就是将要使用的对象都用XML来定义,用反射来生成,用注射的方式来使用. 其实Ioc是工厂模式的升华，Ioc可以被看作是一个大工厂，只不过这个大工厂里要生成的对象都是在XML文件中给出定义的，然后利用Java的“反射”编程，根据XML中给出的类名生成相应的对象。从实现来看，Ioc是把以前在工厂方法里写死的对象生成代码，改变为由XML文件来定义，也就是把工厂和对象生成这两者独立分隔开来，目的就是提高灵活性和可维护性。

Template Method和回调在框架中的使用

Template模式主要是用来解决这样的一个问题:当你知道算法的具体步骤,但不知道如何去执行这些步骤.Template把如何执行这些步骤的方法都封装成抽象的函数,并且提供一个正确的顺序去执行这些步骤,而具体子类实现这些处理各个步骤的抽象方法.

业务逻辑抽象到超类集中化就是所谓的”控制反转”了.在传统的类库中,一般是由客户端来调用类库里的方法.而在这里,却是框架控制了用户流程,具体的子类只是要求履行一个明确的契约.在Spring中的MVC框架里,jdbc包里.都大量的使用了Template模式.

而Java中的回调函数主要是在实现事件驱动模型的时候使用的,但是在Spring里面,回调被赋予了新的意义:通过回调接口(函数)来实现可扩展性.如jdbc包的RowcallbackHandler.