《Head First设计模式》读书笔记 -- （第三章）装饰者模式

本章要点：

1.继承属于扩展形式之一，但不见得是达到弹性设计的最佳方式。

2.在我们的设计中，应该允许行为可以被扩展，而无须修改现有的代码。

3.组合和委托可用于在运行时动态地加上新的行为。

4.除了继承，装饰者模式也可以让我们扩展行为。

5.装饰者模式意味着一群装饰者类，这些类用来包装具体组件。

6.装饰者类反映出被装饰的组件类型（事实上，他们具有相同的类型，都经过接口或继承实现）。

7.装饰者可以在被装饰者的行为前面与/或后面加上自己的行为，甚至将被装饰者的行为整个取代掉，而达到特定的目的。

8.你可以用无数个装饰者包装一个组件。

9.装饰者一般对组件的客户是透明的，除非客户程序依赖于组件的具体类型。

10.装饰者会导致设计中出现许多小对象，如果过度使用，会让程序变得佷复杂。

----------------------------------------分割线 ----------------------------------------

装饰者模式类图：

实例分析：

一个咖啡订单系统，Beverage（饮料）是一个抽象类，店内所提供的饮料都必须继承此类。cost()方法是抽象的，子类必须定义自己的实现。description（叙述）的实例变量，由每个子类设置，用来描述饮料，如“超优深焙咖啡豆”。利用getDescription()方法返回此叙述。购买咖啡时，可以要求在其中加入各种调料，如：牛奶、豆浆、摩卡等。咖啡馆会根据所加入的调料收取不同的费用。如果直接用继承，会造成类爆炸。如果从基类Beverage下手，加上实例变量代表是否加上调料（牛奶、豆浆、摩卡……），看起来是不错，但是不符合我们的设计原则。如调料价钱改变会使我们更改基类代码、一旦出现新的调料，我们就需要加上新方法，并改变超类中的cost()等，所以我们使用到了装饰者模式。

先从Beverage类下手

public abstract class Beverage {
	publicString description = "Uknown Beverage";
	//叙述方法已经实现
	public String getDescription() {
		return description;
	}
	//价钱必须在子类中实现
	public abstract double cost();
}

实现Condiment（调料）抽象类，也就是装饰者类

//必须让CondimentDecorator能够取代Beverage
public abstract class CondimentDecorator extends Beverage {
	//所有装饰者必须重新实现getDescription
	public abstract String getDescription();
}

基类已经有了，现在让我们开始实现一些饮料吧

//让Espresso扩展自Beverage，因为Espresso是一种饮料
public class Espresso extends Beverage {
	//设置饮料的描述
	public Espresso() {
		description = "Espresso";
	}
	//计算Espresso的价钱，现在不需要管调料的价钱
	public double cost() {
		return 1.99;
	}
}

public class HouseBlend extends Beverage {
	public HouseBlend() {
		description = "HouseBlend";
	}
	public double cost() {
		return .89;
	}
}

回头去看看装饰者模式类目，你会发现我们已经完成了抽象组件（Beverage），有了具体组件（HouseBlend），也有了抽象装饰者（CondimentDecorator）。现在，我们就来实现具体装饰者：

//Mocha是一个装饰者，所以扩展自CondimentDecorator
public class Mocha extends CondimentDecorator {
	//用一个实例变量记录饮料，也就是被装饰者
	Beverage beverage;
	//把饮料当做构造器参数，再由构造器将此饮料记录在实例变量中
	public Mocha(Beverage beverage) {
		this.beverage = beverage;
	}
	//利用委托的做法，得到一个叙述，然后在其后加上调料的叙述
	public String getDescription() {
		return beverage.getDescription() + "，Mocha";
	}
	//首先把调用委托给被装饰者对象，然后再加上Mocha的价钱
	public double cost() {
		return .20 + beverage.cost();
	}
}

完成测试代码：

public class App {
	public static void main(String[] args) {
		//订一杯Espresso，不需要调料
		Beverage espresso = new Espresso();
		System.out.println(espresso.getDescription() + " $" + espresso.cost());
		//订一杯调料为摩卡的HouseBlend咖啡
		Beverage houseBlend = new HouseBlend();
		houseBlend = new Mocha(houseBlend);
		System.out.println(houseBlend.getDescription() + " $" + houseBlend.cost());
	}
}

输出： Espresso $1.99

  HouseBlend，Mocha $1.09

上面就是一个完整的装饰者模式实例，可是这样做会有一个问题，在插入装饰者时，必须要小心谨慎。采用装饰者在实例化组件时，将增加代码的复杂度，一旦使用装饰者模式，不只需要实例化组件，还要把此组件包装进装饰者中，天晓得有几个。不过后续还会跟大家介绍工厂模式和生成器模式，它们对这个问题有很大帮助。

总结新的设计原则（开闭原则）：

 对扩展开放，对修改关闭。

装饰者模式动态地将责任附加到对象上。想要扩展功能，装饰者提供有别于继承的另一种选择。