订单处理：模板方法模式

第二十章　订单处理——模板方法模式

20.1　订单处理

时间：1月5日　　地点：大B房间　　人物：大B，小A

这天，大B和小A在讨论怎样去处理订单的问题。

小A：“一个客户可以在个订货单中订购多个货物(也称为订货单项目)，货物的销售价是根据货物的进货价进行计算的。”

大B：“有些货物可以打折的，有些是不可以打折的。每一个客户都有一个信用额度，每张订单的总价不能超出该客户的信用额度。”

小A：“那我们应该怎样去处理这个订单？”

大B：“处理一个订单需要的步聚：1、遍历订货单的订货单项目列表，累加所有货物的总价格(根据订货单项目计算出销售价) 2、根据客户号获得客户的信用额度 3、把客户号，订单的总价格，及订单项目列表写入到数据库。”

小A：“但是我们并不能确定怎么计算出货物的销售价，怎样根据客户号获得客户的信用额度及把订单信息写入数据库这些方法的具体实现？”

大B：“所以用一个抽象类AbstractOrder确定订单处理的逻辑，把不能确定的方法定义为抽象方法,由子类去完成具体的实现。”

20.2　模板方法模式

小A：“通常我们会遇到这样的一个问题：我们知道一个算法所需的关键步聚，并确定了这些步聚的执行顺序。但是某些步聚的具体实现是未知的，或者是某些步聚的实现与具体的环境相关。”

大B：“模板方法模式把我们不知道具体实现的步聚封装成抽象方法，提供一些按正确顺序调用它们的具体方法(这些具体方法统称为模板方法)，这样构成一个抽象基类。子类通过继承这个抽象基类去实现各个步聚的抽象方法，而工作流程却由父类来控制。”

小A：“什么是模板方法模式？”

大B：“定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。”

小A：“要如何去实现它哩？”

大B：“模板模式，是众多模式之中用得比较多的模式，在具体的应用中，我们已经经意或者不经意的采用了这种模式。其是写定义，后实现，然后再调用，将实现与调用分开，从而利用增强了程序的延展性。模板模式是利用了虚函数的多态性，我们可以实现，也可以不实现。”

参考图20-1模板方法模式结构图

图20-1　模板方法模式结构图

代码

AbstractOrder在placeOrder方法中确定了定单处理的逻辑，placeOrder方法也称为模板方法。在placeOrder中调用了三个抽象方法。子类只需要去实现三个抽象方法，而无需要去关心定单处理的逻辑。

20.3　模板方法模式结构

小A：“师兄，能给我讲讲模板方法模式的结构吗？”

大B：“在模板方法模式中有两个参与者进行协作。”

小A：“哪两种参与者？”

大B：“抽象模板类和具体类。”

小A：“什么是抽象模板类？”

大B：“定义一个或多个抽象操作，由子类去实现。这些操作称为基本操作。定义并实现一个具体操作，这个具体操作通过调用基本操作给确定顶级逻辑。这个具体操作称为模板方法。”

小A：“什么是具体类啊？”

大B：“实现抽象模板类所定义的抽象操作。 如上面的订单处理所示：AbstractOrder就是抽象模板类，placeOrder即是抽象模板方法。GetOrderItemPrice，getSpendingLimit和saveOrder三个抽象方法为基本操作。具体子类能过需要去实现这三个抽象方法。不同的子类可能有着不同的实现方式。”

代码

大B：“render_code()；ConcreteOrder为AbstractOrder的具体子类，ConcreteOrder需要去完成具体的三个基本操作。同时他也具有了父类一样的处理逻辑。把具体的实现延迟到了子类去实现，这就是模板方法模式所带来的好处。”

20.4　模板方法模式的目的

小A：“模板方法模式有什么目的？”

大B：“在一个方法中实现一个算法，并将算法中某些步骤的定义推迟，从而使得其他类可以重新定义这些步骤。在编写一个方法的时候，考虑到算法的某些步0骤可能会有不同的实现方式，我们可能会首先定出算法的框架。这样，在定义方法的时候，我们可以将某些步骤定义为抽象方法，或者是将它们定义为存根方法，也可以将它们定义为某个单独接口中的方法，这就是模板方法模式的实现。模板方法的典型例子就是排序。java.util.Collections类将sort()方法定义为一个模板方法，而将其中的比较交给用户来实现，sort()方法所接受的List中的对象需要实现Comparator接口，这就是将实际算法推迟并交给其它类来实现的模板方法模式。”

例：

我们有一个抽象类ShowSubClassName，有两个子类SubClassA和SubClassB继承了该抽象类，抽象类中定义的抽象方法showName()被推迟到了两个子类中实现（分别输出自己的class name）。

20.5　模板方法模式的缺陷

小A：“模板方法模式有什么缺陷？”

大B：“组合优先于继承，而模板方法模式是少数几个必须从非纯虚类（C++的称呼，就是java的interface）继承来实现的模式之一。新手往往颇费周折才能理解其要义，因为它的复杂性-概念复杂性和实现复杂性。而用ioc模式代替继承才是降低复杂性的更好方案。1、概念复杂性。从面向对象方法的本质来讲，父类负责抽象，子类负责具象。而模板方法恰好反过来了，父类实现了大部分功能，而子类实现少数纯虚方法，然后由父类的方法调用。违反了面向对象的一般性思维的原因是这个模式的初衷并不是抽象，而是最大限度的重用。2、实现复杂性。这种重用方式的代价就是每个子类身上都背负了父类强加给它的包袱。”

举个例子：

调用代码：

大B：“这里父类带给子类的负担有两点：1、父类的非默认构建器子类必须重写。2、子类在构建器里使用父类的成员变量时要注意顺序。由此可见，这个模式在提高重用性的同时也增加了复杂性： 1、子类的编写者必须了解父类的实现。2、父类的改动很容易波及到子类。 用IOC组合方式进行就漂亮得多，把子类要实现的方法用interface来描述。这时两个父子关系的类就转变成调用与被调用的关系，之间通过interface形成契约。”

调用代码：

大B：“这两种实现最大的区别是ClassPathContext 和 ApplicationContext 是紧耦合的。而ReaderImpl和ApplicaitonContext是正交的。其次就是IOC方式的实现代码要麻烦，这是Java严谨的语言机制决定的，如果用C# 的Delegate Method来实现要简洁许多。”

20.6　模板方法模式与控制反转

小A：“怎样去理解模板方法模式与控制反转？”(www.xing528.com)

大B：“‘不要给我们打电话，我们会给你打电话’这是著名的好莱坞原则。在好莱坞，把简历递交给演艺公司后就只有回家等待。由演艺公司对整个娱乐项的完全控制，演员只能被动式的接受公司的差使，在需要的环节中，完成自己的演出。模板方法模式充分的体现了‘好莱坞’原则。由父类完全控制着子类的逻辑，这就是控制反转。子类可以实现父类的可变部份，却继承父类的逻辑，不能改变业务逻辑。”

20.7　模板方法模式与开闭原则

小A：“什么是“开闭原则”?”

大B：“是指一个软件实体应该对扩展开放，对修改关闭。也就是说软件实体必须是在不被修改的情况下被扩展。模板方法模式意图是由抽象父类控制顶级逻辑，并把基本操作的实现推迟到子类去实现,这是通过继承的手段来达到对象的复用，同时也遵守了开闭原则。父类通过顶级逻辑，它通过定义并提供一个具体方法来实现，我们也称之为模板方法。通常这个模板方法才是外部对象最关心的方法。在上面的订单处理例子中，public Order placeOrder(int customerId , List orderItemList) 这个方法才是外部对象最关心的方法。所以它必须是public的，才能被外部对象所调用。子类需要继承父类去扩展父类的基本方法，但是它也可以覆写父类的方法。如果子类去覆写了父类的模板方法，从而改变了父类控制的顶级逻辑。这违反了‘开闭原则’。我们在使用模板方法模式时，应该总是保证子类有正确的逻辑。所以模板方法应该定义为final的。 所以AbstractOrder 类的模板方法placeOrder方法应该定义为final。”

代码

大B：“因为子类不能覆写一个被定义为final的方法。从而保证了子类的逻辑永远由父类所控制。模板方法模式中，抽象类的模板方法应该声明为final的。”

20.8　模板方法模式与对象的封装性

小A：“又应该怎样去理解模板方法模式与对象的封装性？”

大B：“面向对象的三大特点：继承，封装，多态。对象有内部状态和外部的行为。封装是为了信息隐藏，通过封装来维护对象内部数据的完整性。使得外部对象不能够直接访问一个对象的内部状态，而必须通过恰当的方法才能访问。在Java语言中，采用给对象属性和方法赋予指定的修改符(public，protected，private)来达到封装的目的，使得数据不被外部对象恶意的访问及方法不被错误调用从而破坏对象的封装性。降低方法的访问级别，也就是最大化的降低方法的可见度是一种很重要的封装手段。最大化降低方法的可见度除了可以达到信息隐藏外，还能有效的降低类之间的耦合度，降低一个类的复杂度。还可以减少开发人员发生的的错误调用。一个类应该只公开外部需要调用的方法。而所有为公开方法服务的方法都应该声明为protected或private。如是一个方法不是需要对外公开的方法，但是它需要被子类进行扩展的或调用。那么把它定义为protected.否则应该为private。显而易见，模板方法模式中的声明为abstract的基本操作都是需要迫使子类去实现的，它们仅仅是为模板方法placeOrder服务的。它们不应该被AbstractOrder所公开，所以它们应该protected。”

代码

模板方法模式中，基本方法应该声明为protcted abstract

20.9　模板方法模式与勾子方法(hookMethod)

大B：“刚才讨论模板方法模式运用于一个业务对象。事实上，框架频繁使用模板方法模式，使得框架实现对关键逻辑的集中控制。”

小A：“我们需要为基本Spring的应用做一个测试用例的基类.用于对类的方法进行单元测试。我们知道Spring应用把需要用到的对象都定义在外部的xml文件中，也称为context。”

大B：“通常我们会把context分割成多个小的文件，以便于管理。在测试时我们需要读取context文件，但是并不是每次都读取所有的文件。读取这些文件是很费时间的。所以我们想把它缓存起来，只要这个文件被读取过一次，我们就把它们缓存起来。所以我们通过扩展Junit的TestCase类来完成一个测试基类。我们需要实现缓存的逻辑，其它开发人员只需要实现读取配置文件的方法即可。它不用管是否具有缓存。”

代码

大B：“render_code();这样子类只需要去实现getConfigLocations方法，提供需要读取的配置文件字符数组就可以了。至于怎么去读取context文件内容，怎么实现缓存，则无需关心。 AbstractCacheContextTests保证在运行所有测试之前去执行读取context文件的动作。 注意这里setUp方法被声明为protected,是因为setUp方法是TestCase类的方法。在这里setUp方法被定义为final了，是确保子类不能去覆写这个方法，从而保证了父类控制的逻辑。 ”

小A：“如果使用过Junit会发生什么问题？”

大B：“TestCase的setUp方法，就是在这个测试类的测试方法运行之前作一些初始化动作。如创建一些所有测试方法都要用到的公共对象等。我们在这里把setUp方法声明为final之后，子类再也无法去扩展它了，子类同时还需要一些额外的初始化动作就无法实现了。可能你会说：‘把setUp方法的final修饰符去掉就可以了啊’。这样是可以的，但是去掉final修饰符后，子类是可以覆写setUp方法，而去执行一些额外的初始化。而可怕的是，父类从此失去了必须读取context文件及缓存context内容的逻辑。为了解决这个问题，我们实现一个空方法onSetUp。在setUp方法中调用onSetUp方法。这样子类就可以通过覆写onSetUp方法来进行额外的初始化。”

//覆写TestCase的setUp方法，在运行测试方法之前从缓存中读取context文件,如果缓存中不存在则初始化applicationContext,并放入缓存.

代码

小A：“为什么不把onSetUp声明为abstract呢？”

大B：“这是因为子类不一定总是需要覆写onSetUp方法。可以说onSetUp方法是为了对setUp方法的扩展。像onSetUp这样的空方法就称之为勾子方法(HookMethod)”

20.10　模板方法模式与策略模式

小A：“模板方法模式与策略模式有什么不同？”

大B：“模板方法模式与策略模式的作用相常类似。有时可以用策略模式替代模板方法模式。模板方法模式通过继承来实现代码复用，策略模式使用委托，委托比继承具有更大的灵活性。继承经常被错误的使用。策略模式把不确定的行为集中到一个接口中，并在主类委托这个接口。”

思考刚才的订单处理例子，改为策略模式后。

1、把不确定的行为抽取为一个接口。

代码

2、而把这个具体类调用这个接口的相应方法来实现具体的逻辑。

代码

大B：“这样Order类不再是一个抽象类，而是一个具体类。Order类委托OrderHelpher接口来完成placeOrder方法所需的基本操作。像在这种情况下使用策略模式更具有优势，策略模式不需要继承来实现。而是通过一个委托对象来实现。OrderHelper接口无需要去继续任何指定的类。而相对来说，采用策略来实现会更复杂一些。由此可见，模板方法模式主要应用于框架设计中，以确保基类控制处理流程的逻辑顺序（如框架的初始化）。像上面的测试基类中。框架通常需要控制反转。而在一些情况中，优级先考虑使用策略模式：当需要变化的操作非常多时，采用策略模式把这些操作抽取到一个接口。当那些基本操作的实现需要与其它类相关时，应该使用策略模式。通过委托接口把行为与实现完全分离出来（比如数据存取）。比如订单处理的saveOrder方法，是写入数据库的。它的实现与你采用何种持久化模式相关。当某些基本操作的实现可能需要在运行时改变时，可以通过在运行时改变委托对象来实现，而继承则不能。所以采用策略模式。”

20.11　支持在屏幕上绘图的类View

大B：“我给你举个例子，你就可以更好在理解模板方法模式了。”

小A：“好。”

大B：“一个支持在屏幕上绘图的类View。一个视图只有在进入焦点状态后时才可以设定合适的特定绘图状态，因而只有成为‘焦点’之后才可以进行绘图。View类强制其子类遵循这个规则。我们用Ｄisplay模板方法来解决这个问题。View定义两个具体方法，SetFocus和ResetFocus,分别设定和清除绘图状态。View的Dodisplay钩子操作实施真正的绘图功能。”

参考图20-2结构图

图20-2　结构图

程序代码：

运行结果：

获得焦点

实现falsh绘图

失去焦点

获得焦点

实现photoshop绘图

失去焦点