C++实现设计模式之装饰者模式详解

目录
  • 设计模式和设计原则
  • 装饰者模式中的类
  • 案列描述
  • 代码实现
  • 总结

设计模式和设计原则

装饰者模式动态地将责任附加到对象上。若要扩展功能,装饰者模式提供了比继承更有弹性的替代方案。

装饰者模式遵循的设计原则

类应该对扩展开放,对修改关闭。

装饰者模式中的类

装饰者模式中的类如下图,C++设计模式之装饰模式

其中Component抽象组件类,即被装饰的类,每个组件都可以单独使用,或者被装饰者包起来使用。该类中声明了一些接口,这些接口将在具体组件,以及具体装饰者中实现。

ConcreteComponent具体组件类,继承自组件类,是我们要动态地加上新行为(即要装饰)的对象。

Decorator抽象装饰者类是具体装饰者的基类,装饰者类中包含一个组件类型的指针,是为了记录被装饰的对象。当需要获得装饰之后的行为时可以通过该指针获得被装饰者的行为加上装饰者自身的行为,这个在下面案例中会看到。

ConcreteDecorator具体装饰者类,装饰者类要实现Decorator中定义的方法,另外可以加一些新的方法。

如上图所示装饰者和被装饰者必须是一样地类型,也就是有共同地超类,这是相当关键的地方。这是因为装饰者必须能取代被装饰者。

案列描述

咖啡馆提供各种各样的咖啡,每种咖啡可以加不同调料(摩卡、奶泡,双糖,半糖等)。以饮料为抽象组件,各种各样的咖啡为具体组件,咖啡中的不同调料为装饰者。每种咖啡以及调料有各自的描述和价格,使用装饰者模式,加了不同调料的咖啡也可以轻松给出描述和价格。

下面例子中生产三种咖啡:不加调料的Espresso、加双倍摩卡一份奶泡的DarkRoast和加双倍奶泡一份摩卡的HouseBlend.。

代码实现

声明:类的声明和实现在同一个文件里是个坏习惯,坏习惯,坏习惯,但因为我懒,还是写一起了,大家不要效仿,要引以为戒,要引以为戒,要引以为戒。

首先定义抽象组件类Beverage和抽象装饰者类CondimentDecorator,代码如下。这里关键的地方是抽象装饰者继承自抽象组件,且包含一个抽象组件的引用。

//抽象组件类-饮料
class Beverage
{
public:
	Beverage() :m_description("Unknown Beverage")
	{
	}
	virtual std::string getDescription(){ return m_description; }
	virtual double cost() = 0;
protected:
	std::string m_description;
};
//抽象装饰者类-调料,继承自饮料类
class CondimentDecorator :public Beverage
{
public:
	CondimentDecorator(Beverage* berverge)
		:m_beverage(berverge)
	{
	}
	virtual std::string getDescription() = 0;//定义成纯虚函数,是为了强制子类实例化时必须实现它。
protected:
	Beverage* m_beverage;
};

然后定义具体组件,即三种具体的咖啡DarkRoast、Espresso和HouseBlend。

//三个具体组件
class DarkRoast :public Beverage
{
public:
	DarkRoast()
	{
		m_description = "DarkRoast";
	}
	double cost()
	{
		return 2.99;
	}
};
class Espresso :public Beverage
{
public:
	Espresso()
	{
		m_description = "Espresso";
	}
	double cost()
	{
		return 1.99;
	}
};
class HouseBlend :public Beverage
{
public:
	HouseBlend()
	{
		m_description = "HouseBlend";
	}
	double cost()
	{
		return 0.89;
	}
};

再定义两个具体装饰者类,即两种调料Mocha和Milk。

//两个具体装饰者
class Mocha :public CondimentDecorator
{
public:
	Mocha(Beverage* beverage) :CondimentDecorator(beverage)
	{
	}
	std::string getDescription()
	{
		return  m_beverage->getDescription() + " Mocha";
	}
	double cost()
	{
		return 0.2 + m_beverage->cost();
	}
};
class Milk :public CondimentDecorator
{
public:
	Milk(Beverage* beverage) :CondimentDecorator(beverage)
	{
	}
	std::string getDescription()
	{
		return  m_beverage->getDescription() + " Milk";
	}
	double cost()
	{
		return 0.5 + m_beverage->cost();
	}
};

最后在main函数中写测试代码,生产三种咖啡:不加调料的Espresso、加双倍摩卡一份奶泡的DarkRoast和加双倍奶泡一份摩卡的HouseBlend.

//测试代码
int main()
{
	//不加调料的Espresso
	Beverage* beverage = new Espresso();
	std::cout << beverage->getDescription() << " ¥" << beverage->cost() << std::endl;
	//加双倍摩卡和奶泡的DarkRoast
	Beverage* beverage2 = new DarkRoast();
	beverage2 = new Mocha(beverage2);
	beverage2 = new Mocha(beverage2);
	beverage2 = new Milk(beverage2);
	std::cout << beverage2->getDescription() << " ¥" << beverage2->cost() << std::endl;
	//加双倍奶泡的和一份摩卡的HouseBlend
	Beverage* beverage3 = new HouseBlend();
	beverage3 = new Mocha(beverage3);
	beverage3 = new Milk(beverage3);
	beverage3 = new Milk(beverage3);
	std::cout << beverage3->getDescription() << " ¥" << beverage3->cost() << std::endl;
	system("pause");
	delete beverage;
	delete beverage2;
	delete beverage3;
}

运行结果

总结

本篇文章就到这里了,希望能够给你带来帮助,也希望您能够多多关注我们的更多内容!

(0)

相关推荐

  • C++设计模式之迭代器模式(Iterator)

    迭代器在STL运用广泛,类似容器的迭代已经成为其重要特性,而迭代器模式则是利用迭代器概念进行的抽象运用,迭代器模式运用广泛和有用,因为其能够不考虑数据的存储方式,而是直接面对数据进行迭代,也就是说我们不用考虑集合是数组(或vector).链表.栈还是队列,而是通过统一的接口进行顺序的访问. 作用 迭代器模式提供了一种顺序访问容器中元素的方法,而无需了解器内部的类型和结构,该模式的核心思想将访问和遍历容器对象的功能交给一个外部的迭代器对象,该迭代器定义了访问聚合对象的接口, 类视图 实现 clas

  • C++设计模式之装饰模式(Decorator)

    装饰模式是一种经典的类功能扩展模式,其精髓在装饰类使用继承加聚合的方式获得接口和要实现对象,然后通过自己实现扩展接口 作用 装饰模式通过装饰类动态地将责任附加到对象上,若要扩展功能,无需通过继承增加子类就能扩展对象的新功能,提供了比继承更有弹性的替代方案,避免了子类数量膨胀带来的系统臃肿. 类视图 代码实现 class Component { public: Component(){} virtual ~Component(){} virtual void operation() = 0; };

  • C++设计模式之适配器模式(Adapter)

    适配器模式顾名思义在于接口的转换,最形象的例子就如两口转三口电源适配器,口子的数量可以理解为参数数量,一如我们调用三个参数的接口,而提供的接口只有两个参数,那么久需要适配器类进行接口的扩展改造,这就是适配器模式存在的最主要意义. 作用 将一个类的接口转换成客户希望的另外一个接口,使得原本由于接口不兼容而不能一起工作的那些类可以一起工作,使控制范围之外的一个原有对象与某个接口匹配.适配器模式主要应用于希望复用一些现存的类,但是接口又与复用环境要求不一致的情况. 想使用一个已经存在的类,但如果它的接

  • C++设计模式之装饰模式

    前言 在实际开发时,你有没有碰到过这种问题:开发一个类,封装了一个对象的核心操作,而这些操作就是客户使用该类时都会去调用的操作:而有一些非核心的操作,可能会使用,也可能不会使用:现在该怎么办呢? 1.将这些非核心的操作全部放到类中,这样,一个类就包含了很多核心的操作和一些看似有关,但是又无关的操作:这就会使核心类发生"爆炸"的现象,从而使核心类失去了一定的价值,也使使用核心类的客户在核心操作和非核心操作中挣扎: 2.使用继承来扩展核心类,需要使用核心类时,直接建立核心类对象:当需要使用

  • C++设计模式之建造者模式(Builder)

    建造者模式与工厂模式最大的区别在与建造者模式更注重的是创建的一系列过程,如流水化作业,工厂模式强调的是区分不同的工厂和产品,而建造者模式更注重的统一不同产品在流水线上的工序,达到统一作业. 作用 建造者模式是将一个复杂对象和他的构造和组装过程分离,这样再重复创建不同对象时使用相同的流程进行建造.对于调用者来说,只需要知道产品的类型,而不需要知道具体的组装过程. 类视图 代码实现 class Builder { public: virtual void SelectCpu()= 0; virtua

  • C++设计模式之观察者模式(Observer)

    观察者模式通常的叫法叫做订阅-发布模式,类似于报刊杂志的订阅,观察者和被观察者就是读者和邮局的关系,读者先要在邮局订阅想要的报刊,当报刊发行时,邮局会将报刊邮寄到读者家里.观察者(Observer)和被观察者(Listener)也是这种关系,Observer将自己attach到Listener中,当Listener触发时Notify所有Observer. 作用 在观察者模式中,被观察者维护观察者对象的集合,当被观察者对象变化时,它会通知观察者.观察者模式主要是用于解决对象之间一对多的关系. 类视

  • Javascript设计模式之装饰者模式详解篇

    一.前言: 装饰者模式(Decorator Pattern):在不改变原类和继承的情况下动态扩展对象功能,通过包装一个对象来实现一个新的具有原对象相同接口的新的对象. 装饰者模式的特点: 1. 在不改变原对象的原本结构的情况下进行功能添加. 2. 装饰对象和原对象具有相同的接口,可以使客户以与原对象相同的方式使用装饰对象. 3. 装饰对象中包含原对象的引用,即装饰对象是真正的原对象经过包装后的对象. 二.Javascript装饰者模式详解: 描述: 装饰者模式中,可以在运行时动态添加附加功能到对

  • C++实现设计模式之装饰者模式详解

    目录 设计模式和设计原则 装饰者模式中的类 案列描述 代码实现 总结 设计模式和设计原则 装饰者模式动态地将责任附加到对象上.若要扩展功能,装饰者模式提供了比继承更有弹性的替代方案. 装饰者模式遵循的设计原则: 类应该对扩展开放,对修改关闭. 装饰者模式中的类 装饰者模式中的类如下图,C++设计模式之装饰模式 其中Component抽象组件类,即被装饰的类,每个组件都可以单独使用,或者被装饰者包起来使用.该类中声明了一些接口,这些接口将在具体组件,以及具体装饰者中实现. ConcreteComp

  • Java设计模式之装饰者模式详解

    目录 具体代码: Person: Student: Doctor: DecoratePerson: ShoeDecorate: DressDecorate: 总结 装饰器模式(Decorator Pattern)允许向一个现有的对象添加新的功能,同时又不改变其结构.这种类型的设计模式属于结构型模式,它是作为现有的类的一个包装. 以一个Person对象为例.Person作为一个接口,Student(学生)和Doctor(医生)为Person接口的两个具体类,DecoratorPerson为Pers

  • 深入理解JavaScript系列(29):设计模式之装饰者模式详解

    介绍 装饰者提供比继承更有弹性的替代方案. 装饰者用用于包装同接口的对象,不仅允许你向方法添加行为,而且还可以将方法设置成原始对象调用(例如装饰者的构造函数). 装饰者用于通过重载方法的形式添加新功能,该模式可以在被装饰者前面或者后面加上自己的行为以达到特定的目的. 正文 那么装饰者模式有什么好处呢?前面说了,装饰者是一种实现继承的替代方案.当脚本运行时,在子类中增加行为会影响原有类所有的实例,而装饰者却不然.取而代之的是它能给不同对象各自添加新行为.如下代码所示: 复制代码 代码如下: //需

  • Java设计模式之装饰者模式详解和代码实例

    装饰者模式可以给已经存在的对象动态的添加能力.下面,我将会用一个简单的例子来演示一下如何在程序当中使用装饰者模式. 1.装饰者模式 让我们来假设一下,你正在寻找一个女朋友.有很多来自不同国家的女孩,比如:美国,中国,日本,法国等等,他们每个人都有不一样的个性和兴趣爱好,如果需要在程序当中模拟这么一种情况的话,假设每一个女孩就是一个Java类的话,那么就会有成千上万的类,这样子就会造成类的膨胀,而且这样的设计的可扩展性会比较差.因为如果我们需要一个新的女孩,就需要创建一个新的Java类,这实际上也

  • Java中常用的设计模式之装饰器模式详解

    目录 优点 缺点 使用场景 一.实现方式 二.测试 总结 优点 1.装饰类和被装饰类可以独立发展,不会相互耦合,装饰模式是继承的一个替代模式,装饰模式可以动态扩展一个实现类的功能. 缺点 2.多层装饰比较复杂. 使用场景 1.扩展一个类的功能. 2.动态增加功能,动态撤销. 一.实现方式 假设一个场景,我们房间每天起床都要刷牙, 睡觉也要刷牙,刷牙的动作就是一个装饰器的作用,这样更利于我们的口腔健康.接下来我们就看看具体的装饰器如何实现. 1.每天生活的接口 package com.asurpl

  • Java设计模式之抽象工厂模式详解

    一.什么是抽象工厂模式 为创建一组相关或相互依赖的对象提供一个接口,而且无需指定他们的具体类,这称之为抽象工厂模式(Abstract Factory).我们并不关心零件的具体实现,而是只关心接口(API).我们仅使用该接口(API)将零件组装称为产品. 二.示例程序   1.抽象的零件:Item类 package com.as.module.abstractfactory; /** * 抽象的零件 * @author Andy * @date 2021/4/29 23:16 */ public

  • Java设计模式之职责链模式详解

    目录 前言 一.职责链模式的定义与特点 二.职责链模式的结构 三.职责链模式案例 前言 本文简单介绍了设计模式的一种--职责链模式  一.职责链模式的定义与特点 定义: 为了避免请求发送者与多个请求处理者耦合在一起,于是将所有请求的处理者通过前一对象记住其下一个对象的引用而连成一条链:当有请求发生时,可将请求沿着这条链传递,直到有对象处理它为止. 比如我们的审批制度,低等级的审批不了的,交给上一级审批,依次类推,直到审批结束. 在责任链模式中,客户只需要将请求发送到责任链上即可,无须关心请求的处

  • Java设计模式中的外观模式详解

    目录 模式介绍 UML类图 外观模式案例: 外观模式的注意事项和细节 模式介绍 外观模式(Facade) ,也叫“过程模式:外观模式为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,这个接口使得这一子系统更加容易使用. 外观模式通过定义一个一致的接口,用以屏蔽内部子系统的细节,使得调用端只需跟这个接口发生调用,而无需关心这个子系统的内部细节. UML类图 类图解析: Facade:为调用端提供统一的调用接口,外观类知道哪些子系统负责处理请求,从而将调用端的请求代理给适当子系统对象

  • JavaScript设计模式之职责链模式详解

    目录 职责链模式 1. 现实中的职责链模式 2. 实际开发中的职责链模式 3. 用职责链模式重构代码 4. 灵活可拆分的职责链节点 5. 异步的职责链 6. 职责链模式的优缺点 7. 用 AOP 实现职责链 8. 小结 职责链模式 职责链模式的定义是:使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系,将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止. 职责链模式的名字非常形象,一系列可能会处理请求的对象被连接成一条链,请求在这些对象之间依次传递,直到遇

随机推荐