装饰模式(Decorator Pattern)--------结构型模式

装饰模式可以在不改变一个对象本身功能的基础上给对象增加额外的新行为。装饰模式降低类系统的耦合度,可以动态地增加或删除对象的职责,并使得需要装饰的具体构件类和具体装饰类可以独立变化,以便增加新的具体构件类和具体的装饰类。在装饰模式中既可以调用待装饰的原有类的方法,还可以增加新的方法,以扩充原有类的功能。

在装饰模式中,为了系统具有更好的灵活性和可扩展性,通常会定义一个抽象装饰类,而将具体的装饰类作为它的子类。

在装饰模式中结构图中包含4个角色

(1)、Component(抽象构件):它是具体构件和抽象装饰类的共同父类,声明了在具体构件中实现的业务方法。它的引入可以使客户端以一致的方式处理未被装饰的对象以及装饰之后的对象,实现客户端的透明操作。

(2)、ConcreteComponent(具体构件):它是抽象构件类的子类,用于定义具体的构件对象,实现了在抽象构件中声明的方法,装饰器可以给它增加额外的职责(方法)。

(3)、Decorator(抽象装饰类):它也是抽象构件类的子类,用于给具体构件增加职责,但是具体职责在其子类中实现。它维护一个指向抽象构件的指针,通过该指针可以调用装饰之前构件对象的方法,并通过其子类扩展该方法,以达到装饰的目的。

(4)、ConcreteDecorator(具体装饰类):它是抽象装饰类的子类,它负责向构件添加新的职责。每一个具体装饰类都定义了一些新的行为,可以调用在抽象装饰类定义的方法,并可以增加新的方法用以扩充对象的行为。

在实际使用过程中,由于新増的欣慰可能需要单独调用,称为半透明(smei-transparent)装饰模式。

1、透明装饰模式

  在透明装换模式中,要求客户端完全针对抽象编程。装饰模式的透明性要求客户端程序不应该将对象声明为具体构件类型或具体装饰类型,而应该全部声明为抽象构件类型。

2、半透明装饰模式

  为了能够调用到新増的方法,须使用具体装饰类型来定义装饰之后的对象,而具体构件类型还是可以使用抽象构件类型来定义,这种装饰模式即为半透明装饰模式。对于客户端而言,具体构件类型无须关心,是透明的;但是具体装饰类型必须指定,这是不透明的。

如果只有一个具体构件类,那么抽象装饰类可以作为具体构件类的直接子类,图示如下:

装饰模式的主要优点:

(1)对于扩展一个对象的功能,装饰模式比继承更加灵活,不会导致类的个数急剧增加。

(2)可以对一个对象进行多次装饰,通过使用不同的具体装饰类以及这些装饰类的排列组合,可以创造出很多不同行为的组合,得到功能更为强大的对象。

(3)具体构件类与具体装饰类可以独立变化,用户可以根据需要增加新的具体构件类和具体装饰类,原有类库代码无须改变,符合开闭原则。

原文地址:https://www.cnblogs.com/openix/p/3251783.html