装饰者模式

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

看下下面的例子,总共有两种咖啡:Decaf、Espresso,另有两种调味品:Mocha、Whip(3种设计的主要差别在于抽象方式不同)

设计一:

即使添加在多的调味品,咖啡依然是咖啡,在抽象的过程中并没有考虑咖啡和调味品之间的关系

当咖啡和调味品的种类很多时,将会产生大量的类,如果一种咖啡的价格发生变动,需要找到所有相关的类逐一修改

设计二:

将调味品作为Coffee类的属性,比起设计一,类的数量大大减少,相应的,程序结构也更加清晰

  1. public class Coffee {  
  2.     private boolean mocha;  
  3.     private boolean whip;  
  4.       
  5.     public double cost(){  
  6.         double price = 0d;  
  7.         if(mocha){  
  8.             price += 0.5;  
  9.         }  
  10.         if(whip){  
  11.             price += 0.1;  
  12.         }  
  13.         return price;  
  14.     }  
  15.       
  16.     public void addMocha(){  
  17.         this.mocha = true;  
  18.     }  
  19.       
  20.     public void addWhip(){  
  21.         this.whip = true;  
  22.     }  
  23. }  
  1. public class Decaf extends Coffee{  
  2.     public double cost(){  
  3.         double price = super.cost();  
  4.         price += 2.0;  
  5.         return price;  
  6.     }  
  7. }  
  1. public class Espresso extends Coffee {  
  2.     public double cost(){  
  3.         double price = super.cost();  
  4.         price += 2.5;  
  5.         return price;  
  6.     }  
  7. }  

测试一下:

  1. public class Test {  
  2.     public static void main(String[] args) {  
  3.         Coffee coffee = new Decaf();  
  4.         coffee.addMocha();  
  5.         coffee.addWhip();  
  6.         //2.6  
  7.         System.out.println(coffee.cost());  
  8.     }  
  9. }  

考虑到下面几个问题,设计二有明显的不足:

1,如果调味品的种类较多,Coffee类将会变得相当庞大,难以维护

2,无法处理顾客希望添加双倍的Mocha的场景

3,添加一种新的咖啡IceCoffee,从逻辑上来说IceCoffee是不能加Mocha的,但是由于IceCoffee类继承自Coffee类,IceCoffee类依然从父类继承了addMocha()方法,这就需要在IceCoffee类中重写一个空的addMocha()方法,并且当使用IceCoffee类时,不能够面向Coffee类编程,以避免错误的调用父类方法

设计三--装饰器模式:

装饰模式分为3个部分:

1,抽象组件 -- 对应Coffee类

2,具体组件 -- 对应具体的咖啡,如:Decaf,Espresso

3,装饰者 -- 对应调味品,如:Mocha,Whip

装饰模式有3个特点:

1,具体组件和装饰者都继承自抽象组件(Decaf、Espresson、Mocha和Whip都继承自Coffee),并且装饰者持有抽象组件的引用

2,可以使用装饰者组合具体组件创造出新的类(Mocha组合Decaf创造出MochaDecaf)

3,过程2可以重复,直到创造出需要的类

使用装饰模式,想要获得一个WhipDoubleMochaEspresso是很容易的:

  1. public interface Coffee {  
  2.     public double cost();  
  3. }  
  1. public class Espresso implements Coffee {  
  2.     public double cost(){  
  3.         return 2.5;  
  4.     }  
  5. }  
  1. public class Dressing implements Coffee {  
  2.     private Coffee coffee;  
  3.       
  4.     public Dressing(Coffee coffee){  
  5.         this.coffee = coffee;  
  6.     }  
  7.       
  8.     public double cost(){  
  9.         return coffee.cost();  
  10.     }  
  11. }  
  1. public class Whip extends Dressing {  
  2.     public Whip(Coffee coffee){  
  3.         super(coffee);  
  4.     }  
  5.       
  6.     public double cost(){  
  7.         return super.cost() + 0.1;  
  8.     }  
  9. }  
  1. public class Mocha extends Dressing {  
  2.     public Mocha(Coffee coffee){  
  3.         super(coffee);  
  4.     }  
  5.       
  6.     public double cost(){  
  7.         return super.cost() + 0.5;  
  8.     }  
  9. }  

测试一下:

  1. public class Test {  
  2.     public static void main(String[] args) {  
  3.         Coffee coffee = new Espresso();  
  4.         coffee = new Mocha(coffee);  
  5.         coffee = new Mocha(coffee);  
  6.         coffee = new Whip(coffee);  
  7.         //3.6(2.5 + 0.5 + 0.5 + 0.1)  
  8.         System.out.println(coffee.cost());  
  9.     }  
  10. }  

当然Decorator类中可以重写父类的方法,也可以扩展自己需要的方法

 

装饰模式的缺点:

1,装饰模式虽然扩展性较高,但是没有设计二简洁,类的数量略多(但肯定比设计一少很多),如何取舍可扩展性和简洁性是个问题,有所选择就要有所牺牲

2,很难搞清楚一个类究竟被装饰了多少层,可能是1层,也可能是100层


  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
装饰者模式(Decorator Pattern)的类图包含以下几个角色: - Component:抽象构件角色,定义一个抽象接口,用来规范具体构件角色和装饰角色的行为。 - ConcreteComponent:具体构件角色,实现 Component 接口,或者继承抽象类 Component,并实现其方法。 - Decorator:抽象装饰角色,继承或实现 Component 接口,包含一个指向 Component 对象的引用,并定义一个与 Component 接口一致的接口。 - ConcreteDecorator:具体装饰角色,继承或实现 Decorator 类,包含一个指向 Component 对象的引用,并可以增加一些额外的功能。 装饰者模式的类图示例如下: ``` +-------------------------+ | Component | +-------------------------+ | +operation() | +-------------------------+ /\ | +-------------------------+ | ConcreteComponent | +-------------------------+ | +operation() | +-------------------------+ /\ | | +-------------------------+ | Decorator | +-------------------------+ | -component: Component | +-------------------------+ /\ | | +-------------------------+ | ConcreteDecorator | +-------------------------+ | -component: Component | | +operation() | +-------------------------+ ``` 在上面的类图中,Component 是抽象构件角色,定义了一个抽象接口 operation(),ConcreteComponent 是具体构件角色,实现了 Component 接口,并且定义了具体的业务方法。Decorator 是抽象装饰角色,继承或实现了 Component 接口,包含一个指向 Component 对象的引用,并定义了一个与 Component 接口一致的接口。ConcreteDecorator 是具体装饰角色,继承或实现了 Decorator 类,包含一个指向 Component 对象的引用,并可以增加一些额外的功能。 在装饰者模式中,客户端可以使用一个或多个装饰器来动态地改变一个对象的行为,而不需要修改原始对象的代码。通过将对象包装在一系列装饰器中,可以在运行时动态地添加或删除功能,从而实现更灵活、更可扩展的设计。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值