本文深入探讨装饰者模式在星巴兹咖啡订单系统中的应用，并通过Java I/O装饰者实例展示其扩展性和灵活性。
转：http://blog.youkuaiyun.com/lissdy/article/details/7540090
星巴兹咖啡准备更新订单系统，以合乎他们的饮料供应需求。
他们原先的类设计为：
这样的订单系统没有办法考虑到咖啡调料的部分，把加入不同调料的咖啡看做不同的类会导致类爆炸（每个类的cost方法计算出咖啡加调料的价钱）：
很明显，这样的系统难以维护，一旦牛奶的价钱上扬或新增一种焦糖调料，系统将难以改变。
采用实例变量和继承的设计也许能解决一些问题：
Beverage作为一个饮料类，加上实例变量代表是否加入了饮料。
然而当用户想要双倍摩卡咖啡时，这样的系统就显得有些无所适从。
对于冰茶，饮料基类里的有些调料根本不适用，但是也一起继承了过来！
到目前为止，使用继承会造成的问题有：类爆炸，设计死板，以及基类加入的新功能并不适用于所有的子类。
所以继承并不是解决问题的方法，应当使用组合来使系统更有弹性且易于维护。
开放-关闭原则：
设计原则：
类应该对扩展开放，对修改关闭。
我们的目标是允许类容易扩展，在不修改现有代码的情况下，就可搭配新的行为。
这个目标需要使用装饰着模式实现：以饮料为主体，然后运行调料来“装饰”饮料。
如图为一个摩卡和奶泡DarkRoast咖啡的设计图：
定义装饰者模式：
装饰者模式动态的将责任附加到对象上，若要扩展功能，装饰者提供了比继承更具有弹性的替代方案。
装饰者模式类图：
现在让星巴兹咖啡系统也符合装饰者类图：
具体实现:
从饮料下手，将饮料作为一个抽象类：
调料抽象类，也就是装饰者类：
实现具体的饮料（浓缩咖啡和综合咖啡）：
实现具体装饰者类（摩卡）
其他装饰者类的实现方式与摩卡类似。
测试代码：
测试结果：
Java中的装饰者模式（java.io类）：
Java I/O引出装饰者模式的一个“缺点”：利用装饰者模式，会造成设计中存在大量的小类。
编写自己的java I/O装饰者，把输入流中的所有大写字母转成小写：
测试程序（测试刚刚写好的I/O装饰者）
测试结果：
转：http://blog.youkuaiyun.com/jason0539/article/details/22713711
另外一个好例子
//定义被装饰者
public interface Human {
public void wearClothes();
public void walkToWhere();
}
//定义装饰者
public abstract class Decorator implements Human {
private Human human;
public Decorator(Human human) {
this.human = human;
}
public void wearClothes() {
human.wearClothes();
}
public void walkToWhere() {
human.walkToWhere();
}
}
//下面定义三种装饰，这是第一个，第二个第三个功能依次细化，即装饰者的功能越来越多
public class Decorator_zero extends Decorator {
public Decorator_zero(Human human) {
super(human);
}
public void goHome() {
System.out.println("进房子。。");
}
public void findMap() {
System.out.println("书房找找Map。。");
}
@Override
public void wearClothes() {
// TODO Auto-generated method stub
super.wearClothes();
goHome();
}
@Override
public void walkToWhere() {
// TODO Auto-generated method stub
super.walkToWhere();
findMap();
}
}
public class Decorator_first extends Decorator {
public Decorator_first(Human human) {
super(human);
}
public void goClothespress() {
System.out.println("去衣柜找找看。。");
}
public void findPlaceOnMap() {
System.out.println("在Map上找找。。");
}
@Override
public void wearClothes() {
// TODO Auto-generated method stub
super.wearClothes();
goClothespress();
}
@Override
public void walkToWhere() {
// TODO Auto-generated method stub
super.walkToWhere();
findPlaceOnMap();
}
}
public class Decorator_two extends Decorator {
public Decorator_two(Human human) {
super(human);
}
public void findClothes() {
System.out.println("找到一件D&G。。");
}
public void findTheTarget() {
System.out.println("在Map上找到神秘花园和城堡。。");
}
@Override
public void wearClothes() {
// TODO Auto-generated method stub
super.wearClothes();
findClothes();
}
@Override
public void walkToWhere() {
// TODO Auto-generated method stub
super.walkToWhere();
findTheTarget();
}
}
//定义被装饰者，被装饰者初始状态有些自己的装饰
public class Person implements Human {
@Override
public void wearClothes() {
// TODO Auto-generated method stub
System.out.println("穿什么呢。。");
}
@Override
public void walkToWhere() {
// TODO Auto-generated method stub
System.out.println("去哪里呢。。");
}
}
//测试类，看一下你就会发现，跟java的I/O操作有多么相似
public class Test {
public static void main(String[] args) {
Human person = new Person();
Decorator decorator = new Decorator_two(new Decorator_first(
new Decorator_zero(person)));
decorator.wearClothes();
decorator.walkToWhere();
}
} //定义被装饰者
public interface Human {
public void wearClothes();
public void walkToWhere();
}
//定义装饰者
public abstract class Decorator implements Human {
private Human human;
public Decorator(Human human) {
this.human = human;
}
public void wearClothes() {
human.wearClothes();
}
public void walkToWhere() {
human.walkToWhere();
}
}
//下面定义三种装饰，这是第一个，第二个第三个功能依次细化，即装饰者的功能越来越多
public class Decorator_zero extends Decorator {
public Decorator_zero(Human human) {
super(human);
}
public void goHome() {
System.out.println("进房子。。");
}
public void findMap() {
System.out.println("书房找找Map。。");
}
@Override
public void wearClothes() {
// TODO Auto-generated method stub
super.wearClothes();
goHome();
}
@Override
public void walkToWhere() {
// TODO Auto-generated method stub
super.walkToWhere();
findMap();
}
}
public class Decorator_first extends Decorator {
public Decorator_first(Human human) {
super(human);
}
public void goClothespress() {
System.out.println("去衣柜找找看。。");
}
public void findPlaceOnMap() {
System.out.println("在Map上找找。。");
}
@Override
public void wearClothes() {
// TODO Auto-generated method stub
super.wearClothes();
goClothespress();
}
@Override
public void walkToWhere() {
// TODO Auto-generated method stub
super.walkToWhere();
findPlaceOnMap();
}
}
public class Decorator_two extends Decorator {
public Decorator_two(Human human) {
super(human);
}
public void findClothes() {
System.out.println("找到一件D&G。。");
}
public void findTheTarget() {
System.out.println("在Map上找到神秘花园和城堡。。");
}
@Override
public void wearClothes() {
// TODO Auto-generated method stub
super.wearClothes();
findClothes();
}
@Override
public void walkToWhere() {
// TODO Auto-generated method stub
super.walkToWhere();
findTheTarget();
}
}
//定义被装饰者，被装饰者初始状态有些自己的装饰
public class Person implements Human {
@Override
public void wearClothes() {
// TODO Auto-generated method stub
System.out.println("穿什么呢。。");
}
@Override
public void walkToWhere() {
// TODO Auto-generated method stub
System.out.println("去哪里呢。。");
}
}
//测试类，看一下你就会发现，跟java的I/O操作有多么相似
public class Test {
public static void main(String[] args) {
Human person = new Person();
Decorator decorator = new Decorator_two(new Decorator_first(
new Decorator_zero(person)));
decorator.wearClothes();
decorator.walkToWhere();
}
} 运行结果：
其实就是进房子找衣服，然后找地图这样一个过程，通过装饰者的三层装饰，把细节变得丰富。
关键点：
1、Decorator抽象类中，持有Human接口，方法全部委托给该接口调用，目的是交给该接口的实现类即子类进行调用。
2、Decorator抽象类的子类（具体装饰者），里面都有一个构造方法调用super(human),这一句就体现了抽象类依赖于子类实现即抽象依赖于实现的原则。因为构造里面参数都是Human接口，只要是该Human的实现类都可以传递进去，即表现出Decorator dt = new Decorator_second(new Decorator_first(new Decorator_zero(human)));这种结构的样子。所以当调用dt.wearClothes();dt.walkToWhere()的时候，又因为每个具体装饰者类中，都先调用super.wearClothes和super.walkToWhere()方法，而该super已经由构造传递并指向了具体的某一个装饰者类（这个可以根据需要调换顺序），那么调用的即为装饰类的方法，然后才调用自身的装饰方法，即表现出一种装饰、链式的类似于过滤的行为。
3、具体被装饰者类，可以定义初始的状态或者初始的自己的装饰，后面的装饰行为都在此基础上一步一步进行点缀、装饰。
4、装饰者模式的设计原则为：对扩展开放、对修改关闭，这句话体现在我如果想扩展被装饰者类的行为，无须修改装饰者抽象类，只需继承装饰者抽象类，实现额外的一些装饰或者叫行为即可对被装饰者进行包装。所以：扩展体现在继承、修改体现在子类中，而不是具体的抽象类，这充分体现了依赖倒置原则，这是自己理解的装饰者模式。
扫一扫
1247
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
