c++设计模式之装饰模式

谁践踏了优雅 2023-06-28 08:47 83阅读 0赞

前言

在实际开发时，你有没有碰到过这种问题；开发一个类，封装了一个对象的核心操作，而这些操作就是客户使用该类时都会去调用的操作；而有一些非核心的操作，可能会使用，也可能不会使用；现在该怎么办呢？

1.  将这些非核心的操作全部放到类中，这样，一个类就包含了很多核心的操作和一些看似有关，但是又无关的操作；这就会使核心类发生“爆炸”的现象，从而使核心类失去了一定的价值，也使使用核心类的客户在核心操作和非核心操作中挣扎；
2.  使用继承来扩展核心类，需要使用核心类时，直接建立核心类对象；当需要使用核心类扩展类时，就建立核心类扩展类对象；这样貌似是一种很有效的方法；但是由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性；同时，又掉入了另一个陷阱，随着扩展功能的增多，子类也会增多，各种子类的组合，就会导致类的膨胀，最后，就会被淹没在类的海洋；此时，也不用我多说，你是不是想起了桥接模式，桥接模式就是为了适应多个维度的变化而发生子类“爆炸”的情况，但是，桥接模式是为了适应抽象和实现的不同变化，并不适用于我这里说的。那如何是好，这就要说到今天总结的装饰模式了。

什么是装饰模式？

在GOF的《设计模式:可复用面向对象软件的基础》一书中对装饰模式是这样说的：动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。

装饰模式能够实现动态的为对象添加功能，是从一个对象外部来给对象添加功能。通常给对象添加功能，要么直接修改对象添加相应的功能，要么派生对应的子类来扩展，抑或是使用对象组合的方式。显然，直接修改对应的类这种方式并不可取。在面向对象的设计中，而我们也应该尽量使用对象组合，而不是对象继承来扩展和复用功能。装饰器模式就是基于对象组合的方式，可以很灵活的给对象添加所需要的功能。装饰器模式的本质就是动态组合。动态是手段，组合才是目的。总之，装饰模式是通过把复杂的功能简单化，分散化，然后再运行期间，根据需要来动态组合的这样一个模式。它使得我们可以给某个对象而不是整个类添加一些功能。

UML类图

![70][]

Component:定义一个对象接口，可以给这些对象动态地添加职责；

ConcreteComponent:定义一个具体的Component，继承自Component，重写了Component类的虚函数；

Decorator:维持一个指向Component对象的指针，该指针指向需要被装饰的对象；并定义一个与Component接口一致的接口；

ConcreteDecorator:向组件添加职责。

代码实现：

#include<iostream>
    using namespace std;
    
    
    //装饰器模式
    class Component
    {
    public:
    	virtual void Operation() = 0;
    };
    
    //没有装饰器的组件,这个可以理解为核心功能
    class ConcreteComponent :public Component
    {
    public:
    	void Operation()
    	{
    		cout << "没有装饰器的组件" << endl;
    	}
    };
    
    
    //装饰器
    class Decorator :public Component
    {
    public:
    	Decorator(Component* pComponent)
    	{
    		m_pComponentObj = pComponent;
    	}
    
    	void Operation()
    	{
    		if (m_pComponentObj!=NULL)
    		{
    			m_pComponentObj->Operation();
    		}
    	}
    protected:
    	Component* m_pComponentObj;
    
    };
    
    
    //用装饰器修饰的组件A
    class ConcreteComponentA :public Decorator
    {
    public:
    	ConcreteComponentA(Component* pComponent):Decorator(pComponent){}
    	void Operation()
    	{
    		addBehavior();    //在核心功能的基础上新增加的装饰器A  
    		Decorator::Operation();
    	}
    	void addBehavior()
    	{
    		cout << "装饰器A" << endl;
    	}
    };
    
    
    //装饰器修饰的组件B
    class ConcreteComponentB :public Decorator
    {
    public:
    	ConcreteComponentB(Component* pComponent) :Decorator(pComponent) {}
    	void Operation()
    	{
    		addBehavior();
    		Decorator::Operation();
    	}
    
    	void addBehavior()
    	{
    		cout << "装饰器B" << endl;
    	}
    };
    
    int main(int argc, char* argv[])
    {
    	Component* component = new ConcreteComponent();
    	Component* componentA = new ConcreteComponentA(component);
    	componentA->Operation();
    	cout << "------------------------" << endl;
    
    
    	Component* componentB = new ConcreteComponentB(component);
    	componentB->Operation();
    	cout << "-------------------------" << endl;
    
    	Component* componentC = new ConcreteComponentB(componentA);
    	componentC->Operation();
    
    	if (component != NULL)
    	{
    		delete component;
    		component = NULL;
    	}
    
    	if (componentA != NULL)
    	{
    		delete componentA;
    		componentA = NULL;
    	}
    
    	if (componentB != NULL)
    	{
    		delete componentB;
    		componentB = NULL;
    	}
    
    	if (componentC != NULL)
    	{
    		delete componentC;
    		componentC = NULL;
    	}
    
    
    	return 0;
    
    }

使用场合

1.  在不影响其他对象的情况下，以动态的，透明的方式给单个对象添加职责；
2.  处理那些可以撤销的职责；
3.  当不能采用生成子类的方法进行扩充时。一种情况是，可能存在大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类。

注意事项

1.  接口的一致性；装饰对象的接口必须与它所装饰的Component的接口是一致的，因此，所有的ConcreteDecorator类必须有一个公共的父类；这样对于用户来说，就是统一的接口；
2.  省略抽象的Decorator类；当仅需要添加一个职责时，没有必要定义抽象Decorator类。因为我们常常要处理，现存的类层次结构而不是设计一个新系统，这时可以把Decorator向Component转发请求的职责合并到ConcreteDecorator中；
3.  保持Component类的简单性；为了保证接口的一致性，组件和装饰必须要有一个公共的Component类，所以保持这个Component类的简单性是非常重要的，所以，这个Component类应该集中于定义接口而不是存储数据。对数据表示的定义应延迟到子类中，否则Component类会变得过于复杂和臃肿，因而难以大量使用。赋予Component类太多的功能，也使得具体的子类有一些它们它们不需要的功能大大增大；

实现要点

1.  Component类在Decorator模式中充当抽象接口的角色，不应该去实现具体的行为。而且Decorator类对于Component类应该透明，换言之Component类无需知道Decorator类，Decorator类是从外部来扩展Component类的功能；
2.  Decorator类在接口上表现为“is-a”Component的继承关系，即Decorator类继承了Component类所具有的接口。但在实现上又表现为“has-a”Component的组合关系，即Decorator类又使用了另外一个Component类。我们可以使用一个或者多个Decorator对象来“装饰”一个Component对象，且装饰后的对象仍然是一个Component对象；
3.  Decortor模式并非解决“多子类衍生的多继承”问题，Decorator模式的应用要点在于解决“主体类在多个方向上的扩展功能”——是为“装饰”的含义；
4.  对于Decorator模式在实际中的运用可以很灵活。如果只有一个ConcreteComponent类而没有抽象的Component类，那么Decorator类可以是ConcreteComponent的一个子类。如果只有一个ConcreteDecorator类，那么就没有必要建立一个单独的Decorator类，而可以把Decorator和ConcreteDecorator的责任合并成一个类。
5.  Decorator模式的优点是提供了比继承更加灵活的扩展，通过使用不同的具体装饰类以及这些装饰类的排列组合，可以创造出很多不同行为的组合；
6.  由于使用装饰模式，可以比使用继承关系需要较少数目的类。使用较少的类，当然使设计比较易于进行。但是，在另一方面，使用装饰模式会产生比使用继承关系更多的对象。更多的对象会使得查错变得困难，特别是这些对象看上去都很相像。

与桥接模式的区别

之前总结了[C++设计模式——桥接模式][C]；你会发现，二者都是为了防止过度的继承，从而造成子类泛滥的情况。那么二者之间的主要区别是什么呢？桥接模式的定义是将抽象化与实现化分离（用组合的方式而不是继承的方式），使得两者可以独立变化。可以减少派生类的增长。如果光从这一点来看的话，和装饰者差不多，但两者还是有一些比较重要的区别：

1.  桥接模式中所说的分离，其实是指将结构与实现分离（当结构和实现有可能发生变化时）或属性与基于属性的行为进行分离；而装饰者只是对基于属性的行为进行封闭成独立的类，从而达到对其进行装饰，也就是扩展。比如：异常类和异常处理类之间就可以使用桥接模式来实现完成，而不能使用装饰模式来进行设计；如果对于异常的处理需要进行扩展时，我们又可以对异常处理类添加Decorator，从而添加处理的装饰，达到异常处理的扩展，这就是一个桥接模式与装饰模式的搭配；
2.  桥接中的行为是横向的行为，行为彼此之间无关联，注意这里的行为之间是没有关联的，就比如异常和异常处理之间是没有行为关联的一样；而装饰者模式中的行为具有可叠加性，其表现出来的结果是一个整体，一个各个行为组合后的一个结果。

总结

装饰模式重点在装饰，对核心功能的装饰作用；将继承中对子类的扩展转化为功能类的组合，从而将需要对子类的扩展转嫁给用户去进行调用组合，用户如何组合由用户去决定。我在学习装饰模式时，就是重点分析了“装饰”这个词，我们都知道，装饰是在一个核心功能上添加一些附属功能，从而让核心功能发挥更大的作用，但是最终它的核心功能是不能丢失的。这就好比我们进行windows shell开发时，我们是对windows的这层壳进行了功能的装饰，从而实现了我们需要的一些装饰功能，但是最终的功能还是由windows shell去完成。这就好比，我们的装饰就是给核心功能添加了一层外衣，让它看起来更漂亮和完美。

[70]: https://img-blog.csdn.net/2018101718241325?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NvZGVyQWxkcmljaA==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70
[C]: https://blog.csdn.net/CoderAldrich/article/details/83115337