设计模式 - 模版方法

约定不等于承诺〃 2022-05-31 05:09 230阅读 0赞

# 设计模式 - 模版方法 #

## 场景 ##

小张的团队最近接受一个需求，实现实现一家咖啡店的冲泡咖啡和茶的冲泡自动化。之前这家咖啡店都是由咖啡师傅手动进行调制咖啡和茶。现在咖啡店需要引入自动化的点单和调制饮料的系统，小张负责实现调制饮料的功能。

咖啡师傅手工冲泡咖啡和茶的流程：

冲泡咖啡：

1.  把水煮沸
2.  用沸水冲泡咖啡
3.  把咖啡倒入杯子
4.  加糖和牛奶

冲泡茶：

1.  把水煮沸
2.  用沸水冲泡茶叶
3.  把茶倒入杯子
4.  加柠檬

小张先简单的想了一下， 如果直接实现程序，那么新建调制咖啡和调制茶的对象，在每个对象里面实现上述步骤。这样想了之后小张本想直接实现，但是由于信心不足，找老王帮他code review一下思路。 老王说，小张啊，你这实现也可以，不过不够优雅啊，你在仔细看一下上述步骤，有没有发现重复或者共性。

小张听了老王的话，觉得自己的设计应该太粗暴了，按照老王的引导，小张仔细看了上述步骤，发现上述步骤，1和4 是很相像的。4（加糖和牛奶/加柠檬）步骤相当于增加调料本质是相同的。那么他应该封装一下冲泡咖啡/茶的步骤算法。

**找出共性进行封装，减少重复代码，使系统达到维护和扩展成本很低的状态。**

老王夸奖到，很不错嘛，小张你已经慢慢的了解了面向对象(OOP)及使用设计模式的原因。你可以了解一下模版方法。

## 模版方法 ##

### 模版方法实现冲泡咖啡 ###

小张去了解了一下模版方法。针对上述冲泡步骤进行了思考。

应该有一个抽象的对象来描述冲泡饮料这一行为，并且抽象的类实现了具体冲泡对象的共性步骤也就是1.把水煮沸和3.把饮料倒入杯子。有两个具体的子类来具体实现冲泡茶和咖啡。  
并且有些客户不需要加调料，那么需要对最后一步进行判断，是否添加调料。

我们来看一下小张的类图：

![E6_A8_A1_E7_89_88_E6_96_B9_E6_B3_95.png_raw_true][]

> 模版方法：在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中。模版方法使得子类可以在不改变算法结构的情况下，重新定义算法中某些步骤。

### 代码实现 ###

#### 冲泡饮料的抽象类 ####

package xuelongjiang.designpartten.templatemethod;
    
    /** * * 模板方法 * * * @Author xuelongjiang */
    abstract   public class CaffeineBeverage { 
    
        //算法。 抽象类的算法是final 的不允许被子类修改
         public final  void   prepareRecipe(){
    
             //算法的具体步骤
             boilWater(); //烧水
             brew();//冲泡
             pourInCup();// 把饮料倒入杯子
             if(hook()){
                 addCondiments();// 加调料
             }
    
        }
    
    
       public  abstract  void brew();
    
       public   abstract  void addCondiments();
    
    
        public void boilWater(){
    
            System.out.println("烧水");
        }
    
    
        public  void pourInCup(){
            System.out.println("把饮料倒入杯子");
        }
    
        /** * 钩子，具体实现可以对算法步骤做一些控制 * * @return */
        public boolean hook(){
            return true;
        }
    
    }

可以看到我们在冲泡咖啡/茶的抽象类中有一个hook方法，这个方法就是钩子方法。默认返回true，如果冲泡咖啡默认是加调料的那么子类就不用重写hook方法。

#### 咖啡类 ####

package xuelongjiang.designpartten.templatemethod;
    
    /** * @Author xuelongjiang */
    public class Coffee extends CaffeineBeverage { 
    
    
        @Override
        public void brew() {
            System.out.println("用沸水冲泡咖啡粉");
        }
    
        @Override
        public void addCondiments() {
            System.out.println("加糖和牛奶");
        }
    
        @Override
        public boolean hook() {
            return super.hook();
        }
    }

#### 茶类 ####

package xuelongjiang.designpartten.templatemethod;
    
    /** * @Author xuelongjiang */
    public class Tea extends CaffeineBeverage { 
    
    
        @Override
        public void brew() {
            System.out.println("用沸水侵泡茶叶");
        }
    
        @Override
        public void addCondiments() {
            System.out.println("加柠檬");
        }
    
    
        @Override
        public boolean hook() {
            return super.hook();
        }
    }

#### 测试类 ####

package xuelongjiang.designpartten.templatemethod;
    /** * @Author xuelongjiang */
    public class TemplateMethodTest { 
    
    
        public static void main(String[] args) {
            CaffeineBeverage caffeineBeverage = new Tea();
            caffeineBeverage.prepareRecipe();
    
            System.out.println("-------------------");
    
            caffeineBeverage = new Coffee();
            caffeineBeverage.prepareRecipe();
    
    
        }
    }

## 模版方法和策略模式的对比 ##

*  模版方法：控制算法内部。
 *  策略模式：不同算法的管理。

还记得我们在[策略模式][Link 1]中武器示例吗？ 拳头，木棍，手枪是实现接口的具体的算法，而不接口的算法内部。

两个模式很相像，但是解决的问题是不同。

## 要点 ##

> 好莱坞原则：别调用（打电话给）我们，我们会调用（打电话给）你。（即高层组件对低层组件的方式是：别调用我们，我们会调用你们）。

*  模版方法定义了算法的步骤，把这些步骤的实现延迟到了子类。
 *  模版方法模式为我们提供了一种代码复用的重要技巧。
 *  模版方法的抽象类可以定义具体方法、抽象方法和钩子。
 *  抽象方法由子类实现。
 *  为了防止子类改变模版方法中的算法，可以将模版方法声明为final
 *  模版方法和策略模式都封装了算法，一个用组合（策略模式），一个用继承（模版方法）。

[E6_A8_A1_E7_89_88_E6_96_B9_E6_B3_95.png_raw_true]: /images/20220531/18430f9f5d184b4bbe0ff18fcf8f04c8.png
[Link 1]: http://blog.csdn.net/u013565163/article/details/78556287