装饰器模式(DECRATOR):
为了实现动态的给对象添加职能,即从外部给对象添加相关职能。可以这样理解,比如说一个Person类,该类的操作有能吃、能睡、能跑、但假如随着人类的进化,某一天Person能飞了,能在水里游了等等,按照一般的写法是修改Person这个类,给这个类添加上能飞,能游等操作,但是这样破坏了面向对象的开放-封闭原则(对修改封闭,对拓展开发,有兴趣的可以查看相关文献),且随着人类的进化这个类就会变得越来越臃肿,越来越复杂,添加任何一个功能都必须对这个臃肿的类进行修改,出错的概率大大提升,且容易影响老功能,而装饰器模式可以解决这类问题,装饰器从外部给类添加职能,而不用去修改原始的类,拓展性好,可复用程度高。
在装饰模式中的各个角色有:
抽象构件(Component)角色:,装饰器和具体需要被装饰的对象都继承自该抽象对象,最重要的一点是Decrator维护了一个需要被装饰的对象的引用,从而达到为该对象添加职能的目的。
具体构件(Concrete Component)角色:定义一个将要接收附加责任的类。
装饰(Decorator)角色:持有一个构件(Component)对象的实例,并定义一个与抽象构件接口一致的接口。
具体装饰(Concrete Decorator)角色:负责给构件对象"贴上"附加的责任。
考虑如下的例子:为一个蛋糕添加装饰。蛋糕店刚生产出来的蛋糕是最原始的,只是一个蛋糕原型,我们需要再这个蛋糕上加上奶油,加上巧克力,加上瓜子仁,写上字等等,将原始蛋糕作为一个Cake类,我们给这个Cake类的对象作装饰,为了不破坏开放-封闭原则,也为了更好的拓展,我们不能直接在Cake这个类里修改,而应该做一个有固定跟你的机器(装饰器),通过装饰器来给这个蛋糕做装饰。
装饰器的UML如下:
代码如下:
component.h//
#ifndef COMPONENT_H_
#define COMPONENT_H_
#include <iostream>
//这个文件描述原始对象和需要被装饰的对象
//定义一个原始的抽象类蛋糕,装饰器的功能是给蛋糕加上各种装饰,如奶油,巧克力,瓜子仁,花生米等
class Cake //原始的抽象类
{
public:
virtual void showCake()=0;
virtual ~Cake(){};
std::string name;
};
class ConcreteCake :public Cake //具体需要被装饰的对象
{
public:
ConcreteCake()
{
name = "原始蛋糕";
}
void showCake(){ std::cout << name.c_str() << std::endl; };
virtual ~ConcreteCake(){};
};
#endif
decorator.h
#include "Component.h"
//文件描述具体的装饰器的类
class CakeDecrator :public Cake
{
protected:
Cake* pCake; //维护一个Cake对象的引用,为Cake对象添加装饰
public:
virtual void showCake() = 0;
virtual ~CakeDecrator(){};
};
class CakeDecratorMilk : public CakeDecrator
{
public:
CakeDecratorMilk(Cake* pCake)
{
this->pCake = pCake;
}
void showCake()
{
this->name = pCake->name + "加奶油";
std::cout << name.c_str()<<std::endl;
};
virtual ~CakeDecratorMilk(){};
};
class CakeDecratorCholate : public CakeDecrator
{
public:
CakeDecratorCholate(Cake* pCake)
{
this->pCake = pCake;
}
void showCake()
{
this->name =pCake->name + "加巧克力";
std::cout << name.c_str() << std::endl;
};
virtual ~CakeDecratorCholate(){};
};
main.cpp
#include "Decrator.h"
int main()
{
ConcreteCake *pConCake = new ConcreteCake();
pConCake->showCake();
CakeDecratorMilk* pDecMilk = new CakeDecratorMilk(pConCake);
pDecMilk->showCake();
CakeDecratorCholate *pDecCho = new CakeDecratorCholate(pDecMilk);
pDecCho->showCake();
delete pConCake;
delete pDecMilk;
delete pDecCho;
return 0;
}
装饰者与建造者模式的区别:
装饰器模式有点类似于建造者模式,两者的区别是建造者模式必须按照统一的步骤来构建某个对象,而装饰器模式不需要,如可以先凃奶油再加巧克力,两者还有一个区别是建造者模式是将对象的构建分为几个步骤,而装饰器模式将已经构建好的对象添加其他部件,就比如说:建造者模式按照统一步骤先造人的头,再造躯干,再造手最后是脚,而装饰器模式是为这个已经建造好的人的对象添加内裤,休闲裤,西装领带等。
装饰者与适配者模式的区别:
1.关于新职责:适配器也可以在转换时增加新的职责,但主要目的不在此。装饰者模式主要是给被装饰者增加新职责的。
2.关于原接口:适配器模式是用新接口来调用原接口,原接口对新系统是不可见或者说不可用的。装饰者模式原封不动的使用原接口,系统对装饰的对象也通过原接口来完成使用。(增加新接口的装饰者模式可以认为是其变种–“半透明”装饰者)
3.关于其包裹的对象:适配器是知道被适配者的详细情况的(就是那个类或那个接口)。装饰者只知道其接口是什么,至于其具体类型(是基类还是其他派生类)只有在运行期间才知道。
要点:
1. 装饰者和被装饰对象有相同的超类型。
2. 可以用一个或多个装饰者包装一个对象。
3. 装饰者可以在所委托被装饰者的行为之前或之后,加上自己的行为,以达到特定的目的。
4. 对象可以在任何时候被装饰,所以可以在运行时动态的,不限量的用你喜欢的装饰者来装饰对象。
5. 装饰模式中使用继承的关键是想达到装饰者和被装饰对象的类型匹配,而不是获得其行为。
6. 装饰者一般对组件的客户是透明的,除非客户程序依赖于组件的具体类型。在实际项目中可以根据需要为装饰者添加新的行为,做到“半透明”装饰者。
适用场景与优缺点:
在以下情况下应当使用装饰模式:
1.需要扩展一个类的功能,或给一个类增加附加责任。
2.需要动态地给一个对象增加功能,这些功能可以再动态地撤销。
3.需要增加由一些基本功能的排列组合而产生的非常大量的功能,从而使继承关系变得不现实。
优点:
- Decorator模式与继承关系的目的都是要扩展对象的功能,但是Decorator可以提供比继承更多的灵活性。
- 通过使用不同的具体装饰类以及这些装饰类的排列组合,设计师可以创造出很多不同行为的组合。
缺点:
- 这种比继承更加灵活机动的特性,也同时意味着更加多的复杂性。
- 装饰模式会导致设计中出现许多小类,如果过度使用,会使程序变得很复杂。
- 装饰模式是针对抽象组件(Component)类型编程。但是,如果你要针对具体组件编程时,就应该重新思考你的应用架构,以及装饰者是否合适。当然也可以改变Component接口,增加新的公开的行为,实现“半透明”的装饰者模式。在实际项目中要做出最佳选择。
来源:CSDN
作者:michael_xh
链接:https://blog.csdn.net/michael_xh/article/details/104579027