设计模式之——装饰模式

1 装饰器模式的定义

装饰器模式: 动态地给一个对象添加一些额外的职责。
就增加功能来说,装饰器模式相比生成子类更为灵活。

装饰模式的通用类图如下:


设计模式之——装饰模式_第1张图片
装饰模式的通用类图
  • Component抽象构件
    Component是一个接口或者抽象类,定义核心对象(原始对象)。
    在装饰器模式中,必然有一个最基本、最核心、最原始的接口或抽象类充当Component抽象构件。
  • ConcreteComponent具体构件
    ConcreteComponent是最核心、最原始、最基本的接口或抽象类Component的实现。装饰器要装饰的就是这个具体构件。
  • Decorator装饰器
    Decorator一般是一个抽象类,用来实现Component抽象构件的接口或者抽象方法。Decorator里面不一定有抽象的方法,但是在它里面一定有一个private属性指向Component抽象构件。
  • ConcreteDecoratorX具体装饰角色
    ConcreteDecoratorX要把ConcreteComponent具体构件装饰成其他东西。

2 装饰器模式代码示例

  1. 抽象构件
public abstract class Component {
    /**
     * 抽象方法
     */
    public abstract void operate();
}
  1. 具体构件
@Slf4j
public class ConcreteComponent extends Component {
    /**
     * 具体实现
     */
    @Override
    public void operate() {
        //具体业务逻辑
        log.info("我是{}.operate()", this.getClass().getName());
    }
}
  1. 抽象装饰器
    如果一个构件只有一个装饰器,并且在可以预见的未来,不会进行扩展,则不需要抽象装饰器角色,直接实现具体的装饰器角色就可以了。
public abstract class AbstractDecorator extends Component {
    private Component component = null;

    /**
     * 构造函数传递被装饰者
     *
     * @param component 被装饰者
     */
    public AbstractDecorator(Component component) {
        this.component = component;
    }

    /**
     * 委托给被装饰者执行
     */
    @Override
    public void operate() {
        this.component.operate();
    }
}
  1. 具体装饰类
  • 具体装饰类ConcreteDecoratorA
@Slf4j
public class ConcreteDecoratorA extends AbstractDecorator {
    /**
     * 构造函数传递被装饰者
     *
     * @param component 被装饰者
     */
    public ConcreteDecoratorA(Component component) {
        super(component);
    }

    /**
     * 具体的修饰方法
     */
    private void method() {
        //业务逻辑A
        log.info("我是{}.method()", this.getClass().getName());
    }

    @Override
    public void operate() {
        //附加特有的修饰方法
        this.method();
        //调用被修饰者
        super.operate();
    }
}
  • 具体装饰类ConcreteDecoratorB
@Slf4j
public class ConcreteDecoratorB extends AbstractDecorator {
    /**
     * 构造函数传递被装饰者
     *
     * @param component 被装饰者
     */
    public ConcreteDecoratorB(Component component) {
        super(component);
    }

    /**
     * 具体的修饰方法
     */
    private void method() {
        //业务逻辑B
        log.info("我是{}.method()", this.getClass().getName());
    }

    @Override
    public void operate() {
        //调用被修饰者
        super.operate();
        //附加特有的修饰方法
        this.method();
    }
}

备注:原始方法和装饰方法的执行顺序在具体的装饰类中是固定的,但是可以通过方法重载来实现多种执行顺序。

  1. 业务场景类
public class Client {
    public static void main(String[] args) {
        Component component = new ConcreteComponent();
        //第一次修饰
        component = new ConcreteDecoratorA(component);
        //第二次修饰
        component = new ConcreteDecoratorB(component);
        //修饰之后运行
        component.operate();
    }
}

运行结果:

23:45:50.753 [main] INFO com.jerry.decorator.ConcreteDecoratorA - 我是com.jerry.decorator.ConcreteDecoratorA.method()
23:45:50.753 [main] INFO com.jerry.decorator.ConcreteComponent - 我是com.jerry.decorator.ConcreteComponent.operate()
23:45:50.753 [main] INFO com.jerry.decorator.ConcreteDecoratorB - 我是com.jerry.decorator.ConcreteDecoratorB.method()

3 装饰器模式的优缺点

3.1 优点

  1. 装饰类和被装饰类可以独立发展,而不会相互耦合
    Component类不需要知道AbstractDecorator类(及其实现类),AbstractDecorator类是从外部开扩展Component类的功能,因此AbstractDecorator类不需要知道具体的构件,降低了耦合性。
  2. 装饰器模式是继承关系的替代方案
    装饰器XxxDecorator不管多少层,返回的对象还是Component,实现的还是is-a关系。
  3. 装饰器可以动态扩展一个实现类的功能

3.2 缺点

多层装饰实现比较复杂。
因此,在使用的过程中,尽量减少装饰器的数量,以便降低系统的复杂度。

4 装饰器使用场景

  1. 需要扩展一个类的功能,或者给一个类增加附加功能。
  2. 需要动态地给一个对象增加功能,这些功能还可以动态地撤销。
  3. 需要为一批的兄弟类进行改装或加装功能,首选装饰器模式。

5 装饰器模式最佳实践

  1. 装饰模式可以有力补充继承
    继承可以解决很多实际问题,但是当继承层数比较深的时候,容易遇到类膨胀的问题,降低系统的可维护性、可扩展性和复用性。另外,继承是静态地给类增加功能,而装饰器模式是动态地增加功能。装饰器模式比继承更加灵活
  2. 在扩展性要求高的系统中使用
    当项目中途业务变更,可能会导致项目延期,可以对原有业务的对象使用装饰器模式来满足新需求而不改变原有业务的代码。
  3. 装饰器模式的层级不要太深
    在使用的过程中,尽量减少装饰器的数量,以便降低系统的复杂度。

参考

  1. 设计模式之禅

你可能感兴趣的:(设计模式之——装饰模式)