Java学设计模式之装饰器模式
一、装饰器模式概念
1.1 什么是装饰器模式
装饰器模式是一种结构型设计模式,它允许向现有对象动态添加新功能,同时又不改变其结构。装饰器模式通过将对象放置在包装器类中,然后在运行时动态地向对象添加新的行为或责任,从而实现这一目的。
结构
装饰器模式通常由以下几个部分组成:
- Component(组件): 定义一个对象接口,可以动态地添加新的职责。
- ConcreteComponent(具体组件): 实现了组件接口,是被装饰的对象。
- Decorator(装饰器): 维持一个指向组件对象的引用,并实现与组件接口一致的接口。
- ConcreteDecorator(具体装饰器): 负责给组件对象添加新的职责。
二、装饰器模式代码
2.1 组件
public interface Coffee {
double cost();
String getDescription();
}
2.2 具体组件
public class SimpleCoffee implements Coffee {
@Override
public double cost() {
return 1.0;
}
@Override
public String getDescription() {
return "一杯咖啡";
}
}
2.3 装饰器
public abstract class CoffeeDecorator implements Coffee {
protected Coffee decoratedCoffee;
public CoffeeDecorator(Coffee decoratedCoffee) {
this.decoratedCoffee = decoratedCoffee;
}
@Override
public double cost() {
return decoratedCoffee.cost();
}
@Override
public String getDescription() {
return decoratedCoffee.getDescription();
}
}
2.4 具体装饰器
public class Milk extends CoffeeDecorator {
public Milk(Coffee decoratedCoffee) {
super(decoratedCoffee);
}
@Override
public double cost() {
return super.cost() + 0.5;
}
@Override
public String getDescription() {
return super.getDescription() + ",加牛奶";
}
}
public class Sugar extends CoffeeDecorator {
public Sugar(Coffee decoratedCoffee) {
super(decoratedCoffee);
}
@Override
public double cost() {
return super.cost() + 0.2;
}
@Override
public String getDescription() {
return super.getDescription() + ",加糖";
}
}
2.5 测试类
public class DecoratorPatternTest {
public static void main(String[] args) {
// 创建一个简单的咖啡
Coffee coffee = new SimpleCoffee();
System.out.println("价格: " + coffee.cost() + ", 成分: " + coffee.getDescription());
// 加入牛奶
coffee = new Milk(coffee);
System.out.println("价格: " + coffee.cost() + ", 成分: " + coffee.getDescription());
// 再加入糖
coffee = new Sugar(coffee);
System.out.println("价格: " + coffee.cost() + ", 成分: " + coffee.getDescription());
// 价格: 1.0, 成分: 一杯咖啡
// 价格: 1.5, 成分: 一杯咖啡,加牛奶
// 价格: 1.7, 成分: 一杯咖啡,加牛奶,加糖
}
}
三、总结
装饰器模式的优点包括:
- 可以动态地添加新的功能,而无需修改现有代码。
- 可以避免使用大量的子类来扩展功能,使代码更加灵活和可维护。
缺点包括:
- 可能会产生大量的具体装饰器类,增加了类的数量和复杂度。
- 装饰器和组件之间的关系可能变得复杂,不易理解。