如果你是J2EE的爱好者,相信你对模板方法并不陌生。是的,很多框架的设计都是基于模板方法。在我看来,我们也能用面向方面的概念来理解模板方法(当然这么说可能不合适)。模板方法的就是将它的部分实现逻辑交给子类去实现。而对于原始基类来说,只是提供一个模板。模板方法完全使用了OO语言的后期动态绑定。
我补充一段模板方法的代码相信大家能对这种架构恍然大悟
public abstract class BaseDBOperator
{
public void insert()
{
doSomeThingBeforeInsert();
doSomeThing();
doSomeThingAfterInsert();
}
protected void doSomeThingBeforeInsert();
protected void doSomeThingAfterInsert();
protected abstract void doSomeThing();
}
我们发现insert的方法已经生成固定的模板,你所要做的就是实现doSomething这个方法。这样就可以将一部分实现提交的到子类。其实我们从架构的角度来看的话,对于insertBeforeInsert这个方法实际上是再doSomething之前切了一个切面。这就是我们说的面向方面。实际上很多框架都提供了面向方面的功能,但是实现的方案可能是多种多样。可能是动态代理,可能是CGLib这种继承等等。但不论哪种,都可以看成是面向方面的概念的实现。好了我们回到工厂方法本身。我们回想一下,实际上对于before和after,不就是提供给我们上下文么?我们知道Activity的回调,它提供一个上下文的环境。Activity的onCreate必须要包含在这个上下文环境中。其实这种以回调的形式给你的也是一种模板方法的一种实现。我们来看看<三国杀>这款游戏:
我们假设说三国杀登陆以后的每一步操作都要进行认证操作。也就是说,你的每一个请求都会检测你的session是否失效,如果失效,那么你将跳出游戏,启动登陆页面:
如果是这样的话是否要在每个服务上增加方法呢?~我们可以参考这种概念设计一种模型
class AbsRequest{
pubic void request() {
this.sessionCheck();
doSomething();
}
abstract void doSomeThing();
public void sessionCheck(){...}
}
我们可以看到我们将session的检测写成了统一的接口,在request请求doSomeThing执行之前使用相同的逻辑。当然实际不会这么简单。但是我们可以参考这种模型来实现我们需要的业务逻辑。