其他分享
首页 > 其他分享> > headFirst设计模式——装饰者模式

headFirst设计模式——装饰者模式

作者:互联网

一旦你熟悉了装饰的技巧,你将能够不修改任何底层代码的情况下,给你的(或别人的)对象赋予新的职责。

一、引入

  星巴兹咖啡因为扩张速度太快了,他们准备更新订单系统,以合乎他们的饮料供应需求。

  原先的设计类:

  

  购买咖啡时,可以加入各种调味。星巴兹会根据加入的调料收取不同的费用。

  

   违反设计原则:封装变化;多用组合,少用继承;

  改法一:应用实例变量和继承。

    1、在基类上加上调料实例,并在cost()方法中实现基本逻辑,让子类继承。

    2、子类可以在其基础价格上加上超类价格(各种调料的价格)。

  思考:一旦出现新的调料,我们要修改基类cost方法。

      出现新的饮品,某些调料可能并不适合。

      万一顾客想要双倍奶泡呢。

  利用组合的方式,可以把设计超类时没有想到的职责加在对象上。而且,可以不用修改原来的代码。

  设计原则:

    类应该对扩展开放,对修改关闭。

    允许类容易扩展,在不修改先有代码的情况下,就可搭配新的行为。(在需要的地方遵循 开放-关闭原则,过度的使用这个原则也是一种浪费,还会导致代码变得复杂且难以理解)。

二、装饰者模式

  以饮料为主题,然后在运行时以调料来“装饰”(decorate)饮料。

  比如说用户想要摩卡和奶泡深焙咖啡,那么,要做的是:

  1、拿一个深焙咖啡(DarkRoast)的对象

  2、以摩卡(Mocha)对象装饰它

  3、以奶泡(whip)对象装饰它

  4、调用cost()方法,并依赖委托(delegate)将调料的价钱加上去

  

   

  小结:

    1、装饰者和被装饰者对象有相同的超类型。

    2、你可以用一个或多个装饰者包装一个对象。

    3、既然装饰者和被装饰者对象有相同的超类型,所以在任何需要原始对象(被包装的)的场合,可以用装饰过的对象代替它。

    4、装饰者可以在所委托被装饰者之前/或之后,加上自己的行为,以达到特定的目的

    5、对象可以在任何时候被装饰,所以可以在运行时动态地、不限量地用你喜欢的装饰者来装饰对象。

  装饰者模式:

    动态的将责任附加到对象上。若要扩展功能,装饰者提供了比继承更有弹性的替代方案。

  

  星巴兹咖啡

  

抽象组件

 1 // Beverage 是一个抽象类
 2 public abstract class Beverage {
 3 
 4     String description = "Unknown Beverage";
 5     
 6     // 对饮品的描述
 7     public String getDescription() {
 8         return description;
 9     }
10     
11     // cost要在子类中实现(都要实现)
12     public abstract double cost();
13 }

 

 

抽象装饰者——调料Condiment抽象类

1 public abstract class CondimentDecorator extends Beverage {
2 
3     public abstract String getDescription();
4 
5 }

具体组件——饮品

 1 public class Espresso extends Beverage {
 2 
 3     public Espresso() {
 4         description = "Espresso";
 5     }
 6 
 7     @Override
 8     public double cost() {
 9         return 2.99;
10     }
11 
12 }

具体装饰者——调料

 1 public class Milk extends CondimentDecorator {
 2 
 3     Beverage beverage;// 用一个实例变量记录饮料,也就是被装饰者
 4     
 5     public Milk(Beverage beverage) {
 6         this.beverage = beverage;// 让被装饰者被记录到实例变量中。把饮料当做构造器参数,再由构造器将此饮料记录在实例变量中
 7     }
 8 
 9     @Override
10     public String getDescription() {
11         // 我们希望描述的不止是饮料,而是完整地连调料都描述出来。
12         return beverage.getDescription()+",Milk";// 我们利用委托的做法,得到一个叙述,然后再加上其他的附加描述。
13     }
14 
15     @Override
16     public double cost() {
17         return beverage.cost() + 0.5;// 调用委托给被装饰对象,以计算价钱,然后再加上调料的价钱。
18     }
19 
20 }

测试

 1 public class StarbuzzCoffee {
 2 
 3     public static void main(String[] args) {
 4         Beverage beverage = new Espresso();
 5         System.out.println(beverage.getDescription()+" $"+beverage.cost());//Espresso $2.99
 6         
 7         Beverage darkRoast = new DarkRoast();
 8         Beverage darkMocha = new Mocha(darkRoast);
 9         Beverage dark2Mocha = new Mocha(darkMocha);
10         Beverage dark2MochaWhip = new Whip(dark2Mocha);
11         System.out.println(dark2MochaWhip.getDescription()+" $"+dark2MochaWhip.cost());
12 //        DarkRoast,Mocha,Mocha,Whip $4.7299999999999995
13         
14         Beverage houseBlend = new HouseBlend();
15         houseBlend = new Soy(houseBlend);
16         houseBlend = new Mocha(houseBlend);
17         houseBlend = new Whip(houseBlend);
18         System.out.println(houseBlend.getDescription() + " $"+houseBlend.cost());
19 //        HouseBlend,Soy,Mocha,Whip $3.2300000000000004
20         
21     }
22     
23 }

  思考:

    1、如果碰到打折呢

    2、如果按大中小杯收费

    3、想要展示Double Mocha 而不是Mocha,Mocha

  优点:

    为设计注入弹性

    透明地插入装饰者,客户程序甚至不需要知道它是在和装饰者打交道

  问题:

    不易理解(要明确这些小类(调料)都是用来包装某个类(饮料)的)

    插入装饰者过多,容易混淆(插入装饰者时要谨慎)

    采用装饰者在实例化组件时,增加代码难度。

    一旦使用装饰者模式,不只需要实例化组件,还要把次组件包装进装饰者中。

  解决:

    工厂(Factory)模式和生成器(Builder)模式,隐藏代码难度。

  

  设计原则:

    1、封装变化

    2、多用组合,少用继承

    3、针对接口编程,不针对实现编程

    4、为交互对象之间的松耦合设计而努力

    5、对扩展开放,对修改关闭

  

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

  

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

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

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

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

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

  装饰者类反映出被装饰的组件类型(事实上,他们具有相同的类型,都经过接口或继承实现)。

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

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

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

  装饰者会导致设计中出现许多小对象,如果过度使用,会让程序变的很复杂。

 

标签:headFirst,cost,Mocha,public,调料,Beverage,设计模式,装饰
来源: https://www.cnblogs.com/onroad2019/p/12911755.html