设计模式学习(九)——模板方法模式

最新推荐文章于 2023-02-22 22:03:07 发布

ssjjy

最新推荐文章于 2023-02-22 22:03:07 发布

阅读量556

点赞数

分类专栏：设计模式文章标签：设计模式模板方法模式

本文链接：https://blog.csdn.net/ssjjy/article/details/22404977

版权

设计模式专栏收录该内容

10 篇文章 0 订阅

订阅专栏

参考书——《HeadFirst设计模式》

和书中一样，用冲咖啡和沏茶来说这个设计模式

冲咖啡：沏茶: 制作饮料：

step1 烧水烧水烧水

step2 用沸水冲咖啡粉用沸水冲茶叶 ===========》用沸水冲

step3 倒入杯中倒入杯中倒入杯中

step4 加糖加奶加柠檬加适当的调料

我们看到step1和step3是一样的，换而言之，可以具体实现，step2和step4虽然不一样但是我们可以进行提取，也就是抽象。等等，想到了什么？！抽象类 P.s:抽象类和接口的区别http://dev.yesky.com/436/7581936.shtml

public abstract class Beverage {
	
	final void prepareRecipe() {
		boilwater();
		brew();
		pourIncup();
		addCondiments();
	}
	
	abstract void brew();
	
	abstract void addCondiments();
	
	void boilwater() {
		System.out.println("烧水");
	}
	
    void pourIncup() {
    	System.out.println("倒入杯中");
	}
}

模板方法——就是这里的prepareRecipe()，它定义了一个算法的步骤，并允许子类为一个或多个步骤提供实现。

“炫酷的地方”：1）Beverage类主导一切，它拥有这个算法，并且保护这个算法；

2）对子类来说，Beverage类的存在，可以提高代码的复用；

3）算法存在一个地方，便于维护；

4）模板方法提供了一个框架，可以让其他的饮料插进来，新的饮料只要实现自己的方法就行；

5）Beverage类专注在算法本身，而由子类提供完整的实现。

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

其实，模板就是一个方法。更具体地说，这个方法将算法定义成一组步骤，其中任何步骤都可以是抽象的，由子类负责实现，这可以确保算法的结构保持不变，同时由子类提供部分实现。模板方法本身和这些抽象的原语操作的具体实现之间解耦了。

有了这个抽象类，我们就可以写具体的Coffee和Tea类了，代码如下：

public class Coffee extends Beverage {

	void brew() {
		System.out.println("用沸水冲咖啡");
    }
    
	void addCondiments() {
		System.out.println("加糖加奶");
    }

}

到这里，发现问题了，冲杯Coffee，前三个步骤是必须的，但是添加调料就不是必须的了，有的人不喜欢给咖啡里加糖加奶，怎么办？

基于这个问题我们引出"钩子"方法：

在上面的链接的这篇文章里，有一段话“在abstract class的定义中，我们可以赋予方法的默认行为。”

对此我的理解：给一个方法赋予默认行为，这个方法是子类可以重写也可以不重写，子类可以通过重写来提升方法的性能，这样的方法就可以成为“钩子”方法。有人会说，普通的方法（没有被final修饰）也可以做到可以重写也可以不重写啊。难道都是“钩子”方法？！

在别人的博客看到这样的话：“继承包含这样一层含义：父类中凡是已经实现好的方法（相对于抽象方法而言），实际上是在设定一系列的规范和契约，虽然它不强制要求所有的子类必须遵从这些契约，但是如果子类对这些非抽象方法任意修改，就会对整个继承体系造成破坏。”

所以，我觉得“钩子”方法和普通方法，其实是个度的问题，普通方法，就如上面这段话的红色字所说，它有它自己规定的契约，不太希望被改变。而“钩子”方法是规定了默认行为（这个默认行为甚至可以为空，“钩子”方法什么都不做），最为宽泛的，子类可以在其上进行规定。

接下来，我们看看如何用"钩子"方法解决上面的问题——有的人不喜欢给咖啡里加糖加奶，怎么办？

先来看Beverage类：

public abstract class Beverage {
	
	final void prepareRecipe() {
		boilwater();
		brew();
		pourIncup();
		if(customerWantsCondiments()){
			addCondiments();
		}
	}
	
	abstract void brew();
	
	abstract void addCondiments();
	
	void boilwater() {
		System.out.println("烧水");
	}
	
    void pourIncup() {
    	System.out.println("倒入杯中");
	}
    
    boolean customerWantsCondiments() {
    	return true;
    }
}

这个customerWantsCondiments（）就是一个“钩子”方法，只会返回true，不做别的事，子类可以覆盖也可以不覆盖。

再来看Coffee类：

public class Coffee extends Beverage {

	void brew() {
		System.out.println("用沸水冲咖啡");
    }
    
	void addCondiments() {
		System.out.println("加糖加奶");
    }
	
	boolean customerWantsCondiments() {
    	String answer = getUserInput();
    	if(answer.toLowerCase().startsWith("y")){
    		return true;
    	}else{
    		return false;
    	}
    }
	
	public String getUserInput() {
		String answer = null;
		System.out.println("需要加糖加奶么？(y/n)");
		BufferedReader in = new BufferedReader(new InputStreamReader(System.in));
		try{
			answer = in.readLine();
		}catch(IOException e){
			System.out.println("抱歉，出错了！");
		}
		if(answer==null){
			answer = "no";
    	}
		return answer;
	}
}

问题解决了!“钩子”方法竟然能够作为条件控制,影响抽象类中的算法流程，实在不赖吧