前言
距离上一篇，间隔时间有点长哈(尴尬 ==!)
经历过漫长的实习期，试用期，第一份工作终于慢慢走上正轨，中间发生了很多事情，有好有坏，回头看看，也不能说谁对谁错，只是立场不同罢了，都是选择罢了。
废话不多说，开始进入今天的主题，装饰器模式。
设计模式分类
- 有说分为3类的：创建型，结构型(装饰器模式属于这种)，行为型 —— 参考设计模式总结之模式分类一文；
- 也有说分成5类的：接口型模式，职责型模式，构造型模式，操作型模式，扩展型模式(装饰器模式属于这种) —— 参考(给自己备忘)常用的5类23种设计模式一文。
唔，我觉的都行，互补的看吧。
相关概念
- 定义：装饰模式是一种对象结构型模式
- 功能：动态地给一个对象增加一些额外的职责(也就是扩展)
- 优点：比生成子类实现更为灵活，比直接修改该类更符合开放关闭原则
- 缺点：装饰者会导致设计中出现许多小对象，如果过度使用，会让程序变得很复杂，最好配合工厂或生成器这样的模式一起使用
情景代入
好吧，概念什么的太枯燥了，还是喜欢简单粗暴的方式，直接情景代入。哦，这里推荐 Head First 系列哈，有的图我就直接拿来用了。
额，我不懂咖啡，也不喜欢喝，太苦。+ +
所以，不要用什么分类错误，不懂咖啡这点来怼我哈，小心脏，受不来哦 + +
如下图，咖啡厅里有饮料(抽象类)，有各种咖啡(4个子类)，都有一个计算价格的cost()继承自Beverage类。
饮料及其子类
需求变化
- 假设，这个时候需要多加一种新咖啡，就意味着，需要有一个新的子类，同时需要复写cost()，对吧？那如果多加10种咖啡呢？100种呢？可以预见的是，随着咖啡厅业务的发展，咖啡种类，越来越多，子类的是数量会爆炸的！！！
后来发现，这里的“种”有歧义，稍微解释一下，现实生活中，拿铁，摩卡等算是一种咖啡，但是在代码里，配料的组合方式不同，就是不同种类的咖啡。
比如：拿铁咖啡，配牛奶，配糖，为种类一；
拿铁咖啡，配豆浆，配糖，就为种类二；
拿铁咖啡，配豆浆*2，配糖，就为种类三；
排列组合计算一下，有多少种咖啡，就有多少子类 +_+
- 假设，配料的价格发生变化，比如牛奶的涨价了，那么所有含有牛奶的咖啡价格都会发生变化，相应的cost()需要修改，这个改动可是很大的！！！
针对以上两点，我们发现继承的确很好的使得，所有子类都拥有和父类一样的cost()行为，但是在代码的可维护性上表现的并不好，这个时候，我们可以尝试组合(装饰)的方式。
初识装饰器
我们已经了解单独利用继承无法完全解决问题，所以，在这里要采用不一样的做法：我们要以饮料为主体，然后在需要时以配料来装饰(decorate)饮料。比方说，如果顾客想要加摩卡和奶泡的深焙咖啡，那么，要做的是:
-
获取一个深焙咖啡(DarkRoast)对象
DarkRoast
-
以摩卡(Mocha)对象装饰它
Mocha Wrap
-
以奶泡(Whip)对象装饰它
Whip Wrap
-
调用cost()方法，将调料的价钱加上去，得出总价
cost().png
装饰器模式关键点
- 装饰者和被装饰对象有相同的超类型。
关于这个，我需要解释一下，相同的超类行，是为了保证类型一致。
我们需要装饰者必须能取代被装饰者，才能被下一个装饰者叠加装饰。
继承在通常的情况下有两个功能，1.类型匹配 2.获得行为。这里用的是第一个功能。
- 你可以用一个或多个装饰者包装一个对象。
- 既然装饰者和被装饰对象有相同的超类型，所以在任何需要原始对象(被包装的)的场合， 可以用装饰过的对象代替它。
- 装饰者可以在所委托被装饰者的行为之前与/或之后，加上自己的行为，以达到特定的目的 —— 最关键的点。
- 对象可以在任何时候被装饰，所以可以在运行时动态地、不限量地用你喜欢的装饰者来装饰对象。
结构梳理
直接看图吧，文字描述，太臃肿，还不好理解 + +
整体结构设计
代码实现
- 自然是Beverage类(被装饰者)了
/**
* 饮料的基类
*/
public abstract class Beverage {
/**
* 饮料的描述
*/
String description = "饮料(基类)";
public String getDescription() {
return description;
}
/**
* 计算总价：
* v1：饮料本身的价格+原材料的价格
* v2：饮料本身的价格+原材料的价格*数量
* v3：饮料本身的价格+原材料的价格*数量+杯子的大小容量(小杯，大杯)
*/
public abstract double cost();
}
- 为了简单，我就只写两个子类哈
public class Decaf extends Beverage {
public Decaf() {
description = "低咖啡因咖啡";
}
@Override
public double cost() {
return 1.05; //该咖啡本身的价格
}
}
public class DarkRoast extends Beverage {
public DarkRoast() {
description = "深焙咖啡";
}
@Override
public double cost() {
return 0.99; //该咖啡本身的价格
}
}
- 配料(装饰者)的基类
/**
* 基础配料(装饰者)
*/
public abstract class CondimentDecorator extends Beverage {
/**
* 由子类去实现，返回具体的描述
*/
public abstract String getDescription();
}
- 为了简单，我也只写两个哈
public class Milk extends CondimentDecorator {
Beverage beverage;
/**
* 关键点，装饰者的构造器中，需要把被装饰的对象传进来
*/
public Milk(Beverage beverage) {
this.beverage = beverage;
}
/**
* 描述，先把之前的装饰行为描述出来，再追加这次的
*/
@Override
public String getDescription() {
return beverage.getDescription() + ", 牛奶";
}
/**
* 价格也一样，先把之前的价格累加，再追加这次的
*/
@Override
public double cost() {
return beverage.cost() + 0.10;
}
}
public class Soy extends CondimentDecorator {
Beverage beverage;
public Soy(Beverage beverage) {
this.beverage = beverage;
}
@Override
public String getDescription() {
return beverage.getDescription() + ", 豆浆";
}
@Override
public double cost() {
return beverage.cost() + 0.15;
}
}
- 接下来，就是看结果的时候了
public class StarbuzzCoffee {
public static void main(String[] args) {
Beverage beverage1 = new Espresso();
System.out.println(beverage1.getDescription() + " $" + beverage1.cost());
Beverage beverage2 = new DarkRoast();
beverage2 = new Mocha(beverage2);
beverage2 = new Mocha(beverage2);
beverage2 = new Whip(beverage2);
System.out.println(beverage2.getDescription() + " $" + beverage2.cost());
Beverage beverage3 = new HouseBlend();
beverage3 = new Soy(beverage3);
beverage3 = new Mocha(beverage3);
beverage3 = new Whip(beverage3);
System.out.println(beverage3.getDescription() + " $" + beverage3.cost());
}
}
-
结果如图
关于有强迫症的同学们，不希望“摩卡”出现两次，一些要写成“摩卡*2”才舒服的话，需要自己去改写 CondimentDecorator 中 getDescription()，使其返回 ArrayList 类型，让每个配料名称独立，那么 CondimentPrettyPrint() 会更容易编写e。
image.png
- 总结一下
装饰器 = 继承(被装饰者：咖啡) + 组合(行为) + 继承(配料：牛奶)
开-闭原则
之前提到过，开放-关闭原则，这里简单说一下：类应该对扩展开放，对修改关闭。
- 面对快速变化的千奇百怪的需求(程序猿永远的痛)，扩展性的重要性就不必多说了
- 关闭修改，对于之前写好的代码， 经过了测试同学的努力，终于确认相对安全后，最好最好最好不要再次修改，复制粘贴都别，以防万一！！！如果你对这点有疑问，你应该去找你的经理谈谈心～～
Java I/O
这是一个最常见的运用装饰器模式的案例。直接上图。
Java I/O
很眼熟吧，那就证明装饰器模式在你的脑海里，占用了一些神经元和活性突触(哈哈，得瑟一下 ^6^)
从这里也引出了装饰器模式的一个不好的点：利用装饰者模式，常常造成设计中有大量的小类，数量实在太多，可能会造成使用者的困扰。我尤记得当初学Java基础时，觉得I/O好难，不就是因为这种流那种流太多太难记了么= =
再多说几句
- 采用装饰者在实例化组件时，将增加代码的复杂度。一旦使用装饰者模式，不只需要实例化组件，还要把此组件包装进装饰者中，天晓得有几个，就像这样：
Beverage beverage2 = new DarkRoast();
beverage2 = new Mocha(beverage2);
beverage2 = new Mocha(beverage2);
beverage2 = new Whip(beverage2);
beverage2 = new Mocha(beverage2);
beverage2 = new Mocha(beverage2);
beverage2 = new Whip(beverage2);
beverage2 = new Mocha(beverage2);
beverage2 = new Mocha(beverage2);
beverage2 = new Whip(beverage2);
...
要写多少次？所以，要借助工厂(Factory)模式和生成器(Builder)模式配合使用
- 我在学习过程中，这样的说法：
- 并不是所有可以使用适配器模式的地方，都必须去使用，要根据成本去抉择使用与否。额，这句话就是需要大量的项目经验才能去衡量平衡了，我目前说不清楚。
- 如果代码写成依赖于具体的组件类型，那么装饰者就会导致程序出问题。只有在针对抽象组件类型编程时，才不会因为装饰者而受到影响。这句话，我也不是很理解，感觉很玄学 + +
- 哦，对了对了，差点忘记了，这个装饰器模式和Kotlin中的扩展函数有点相似，当然后者简洁的多，有兴趣的朋友可以去看看～～
网友评论