设计模式 之 Bridge，Adapter，Decorator，Composite，Proxy

最新推荐文章于 2021-10-18 15:11:16 发布
最新推荐文章于 2021-10-18 15:11:16 发布
阅读量371 收藏 2
点赞数
文章标签： 设计模式 c++
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/yumiano0/article/details/104096616
版权

Bridge Pattern

问题：

在面向对象中，代码结构设计的目标就是“松耦合，高内聚”，尽可能提高系统模块的内部的内聚，尽可能降低模块之间的耦合；有一个对应的原则是 “Favor Composition Over Inheritance”;

方案：

Bridge模式可以实现固定工作流和具体实现解耦，一般有两个类，一个Abstraction，含有一个似有指针成员指向AbstractionImp对象，而另一个AbstractionImp类封装具体的实现细节，在需求发生频繁变动的开发中，具有明显的优势。
也可以解除编译依赖 编码规范。
在这里插入图片描述

Code:
//Abstraction.h
#ifndef _ABSTRACTION_H_
#define _ABSTRACTION_H_
class AbstractionImp;
class Abstraction
{
public:
	virtual ~Abstraction();
	virtual void Operation() = 0;
protected:
	Abstraction();
private:
};

class RefinedAbstraction:public Abstraction
{
public:
	RefinedAbstraction(AbstractionImp* imp);
	~RefinedAbstraction();
	void Operation();
protected:
private:
	AbstractionImp* _imp;
};
#endif //~_ABSTRACTION_H_

//Abstraction.cpp
#include "Abstraction.h"
#include "AbstractionImp.h"
#include <iostream>
using namespace std;
Abstraction::Abstraction()
{
}
Abstraction::~Abstraction()
{
}
RefinedAbstraction::RefinedAbstraction(AbstractionImp* imp)
{
	_imp = imp;
}
RefinedAbstraction::~RefinedAbstraction()
{
}
void RefinedAbstraction::Operation()
{
	_imp->Operation();
}

//AbstractionImp.h
#ifndef _ABSTRACTIONIMP_H_
#define _ABSTRACTIONIMP_H_
class AbstractionImp
{
public:
	virtual ~AbstractionImp();
	virtual void Operation() = 0;
protected:
	AbstractionImp();
private:
};
class ConcreteAbstractionImpA:public AbstractionImp
{
public:
	ConcreteAbstractionImpA();
	~ConcreteAbstractionImpA();
	virtual void Operation();
protected:
private:
};
class ConcreteAbstractionImpB:public AbstractionImp
{
public:
	ConcreteAbstractionImpB();
	~ConcreteAbstractionImpB();
	virtual void Operation();
protected:
private:
};
#endif //~_ABSTRACTIONIMP_H_

//AbstractionImp.cpp
#include "AbstractionImp.h"
#include <iostream>
using namespace std;
AbstractionImp::AbstractionImp()
{
}
AbstractionImp::~AbstractionImp()
{
}
void AbstractionImp::Operation()
{
	cout<<"AbstractionImp....imp..."<<endl;
}
ConcreteAbstractionImpA::ConcreteAbstractionImpA()
{
}
ConcreteAbstractionImpA::~ConcreteAbstractionImpA()
{
}
void ConcreteAbstractionImpA::Operation()
{
	cout<<"ConcreteAbstractionImpA...."<<endl;
}
ConcreteAbstractionImpB::ConcreteAbstractionImpB()
{
}
ConcreteAbstractionImpB::~ConcreteAbstractionImpB()
{
}
void ConcreteAbstractionImpB::Operation()
{
	cout<<"ConcreteAbstractionImpB...."<<endl;
}

//main.cpp
#include "Abstraction.h"
#include "AbstractionImp.h"
#include <iostream>
using namespace std;
int main(int argc,char* argv[])
{
	AbstractionImp* imp = new ConcreteAbstractionImpA();
	Abstraction* abs = new RefinedAbstraction(imp);
	abs->Operation();
	return 0;
}

Adapter Pattern

问题：

开发过程中，需要不同模块之间相互配合工作，但是当别的团队或者购买的第三方模块设计的对外接口和自己开发模块的接口不一致，在不同的接口之间作兼容？

方案：

Client想要调用目标类的request方法，但是Adaptee对象提供了SpecificRequest方法,所以Adapter需要处理之间的接口不一致情形。
方法1：类模式
使用继承的方法，让Adapter继承Adaptee类，封装方法，让client调用；
在这里插入图片描述
方法2：对象模式
类之间为组合的关系，让Adapter去持有Adpatee成员并调用SpecificRequest的方法并对外公开Request接口即可。
在这里插入图片描述

code:

类模式：

//Adapter.h
#ifndef _ADAPTER_H_
#define _ADAPTER_H_
class Target
{
public:
Target();
virtual ~Target();
virtual void Request();
protected:
private:
};
class Adaptee
{
public:
Adaptee();
~Adaptee();
void SpecificRequest();
protected:
private:
};
class Adapter:public Target,private Adaptee
{
	public:
	Adapter();
	~Adapter();
	void Request();
	protected:
	private:
};
#endif //~_ADAPTER_H_

//Adapter.cpp
#include "Adapter.h"
#include <iostream>
Target::Target()
{
}
Target::~Target()
{
}
void Target::Request()
{
	std::cout<<"Target::Request"<<std::endl;
}
Adaptee::Adaptee()
{
}
Adaptee::~Adaptee()
{
}
void Adaptee::SpecificRequest()
{
	std::cout<<"Adaptee::SpecificRequest"<<std::endl;
}
Adapter::Adapter()
{
}
Adapter::~Adapter()
{
}
void Adapter::Request()
{
	this->SpecificRequest();
}

//main.cpp
#include "Adapter.h"
#include <iostream>
using namespace std;
int main(int argc,char* argv[])
{
	//Adapter* adt = new Adapter();
	Target* adt = new Adapter();
	adt->Request();
	return 0;
}

对象模式：

//Adapter.h
#ifndef _ADAPTER_H_
#define _ADAPTER_H_
class Target
{
	public:
	Target();
	virtual ~Target();
	virtual void Request();
	protected:
	private:
};
class Adaptee
{
	public:
	Adaptee();
	~Adaptee();
	void SpecificRequest();
	protected:
	private:
};
class Adapter:public Target
{
	public:
	Adapter(Adaptee* ade);
	~Adapter();
	void Request();
	protected:
	private:
	Adaptee* _ade;
};
#endif //~_ADAPTER_H_

//Adapter.cpp
#include "Adapter.h"
#include <iostream>
Target::Target()
{
}
Target::~Target()
{
}
void Target::Request()
{
	std::cout<<"Target::Request"<<std::endl;
}
Adaptee::Adaptee()
{
}
Adaptee::~Adaptee()
{
}
void Adaptee::SpecificRequest()
{
	std::cout<<"Adaptee::SpecificRequest"<<std::endl;
}
Adapter::Adapter(Adaptee* ade)
{
	this->_ade = ade;
}
Adapter::~Adapter()
{
}
void Adapter::Request()
{
	_ade->SpecificRequest();
}

//main.cpp
#include "Adapter.h"
#include <iostream>
using namespace std;
int main(int argc,char* argv[])
{
	Adaptee* ade = new Adaptee;
	Target* adt = new Adapter(ade);
	adt->Request();
	return 0;
}
总结：

接口继承指的是通过继承,子类获得了父类的接口，可以对外公开,而实现继承指的是通过继承子类获得了父类的实现(并不接口)。在 C++中的 public 继承既是接口继承又是实现继承,因为子类在继承了父类后既可以对外提供父类中的接口操作,又可以获得父类的接口实现。

Decorator Pattern

问题：

为已经定义好的类添加新的操作，而通过继承来扩展接口成本太高。
如何实现动态灵活的为对对象添加功能？

方案：

通过组合来实现扩展
在这里插入图片描述1. ConcreteComponent 和 Decorator 需 要 有 同 样 的 接 口 , 因 此ConcreteComponent 和 Decorator 有着一个共同的虚基类Component用于封装对外的接口。
2. ConcreteComponent 定义了一个具体的对象，继承并扩展Component，可以为其添加职责，是添加装饰的基础对象。
3. Decorator，装饰抽象类，继承Component，从外类来扩展Component类的功能（ConcreteComponent对象是其成员），但是对于Component来说，是无需知道Decorator的存在的。
4. Decorator通过调用ConcreteComponent的接口并扩展，完成增加职能的任务，但是对外接口依然是不变的；

Code:
//Decorator.h
#ifndef _DECORATOR_H_
#define _DECORATOR_H_
class Component
{
	public:
	virtual ~Component();
	virtual void Operation();
	protected:
	Component();
	private:
};

class ConcreteComponent:public Component
{
	public:
	ConcreteComponent();
	~ConcreteComponent();
	void Operation();
	protected:
	private:
};

class Decorator:public Component
{
	public:
	Decorator(Component* com);
	virtual ~Decorator();
	void Operation();
	protected:
	Component* _com;
	private:
};

class ConcreteDecorator:public Decorator
{
	public:
	ConcreteDecorator(Component* com);
	~ConcreteDecorator();
	void Operation();
	void AddedBehavior();
	protected:
	private:
};
#endif //~_DECORATOR_H_

//Decorator.cpp
#include "Decorator.h"
#include <iostream>
Component::Component()
{
}
Component::~Component()
{
}
void Component::Operation()
{
}
ConcreteComponent::ConcreteComponent()
{
}
ConcreteComponent::~ConcreteComponent()
{
}
void ConcreteComponent::Operation()
{
	std::cout<<"ConcreteComponent operation..."<<std::endl;
}
Decorator::Decorator(Component* com)
{
	this->_com = com;
}
Decorator::~Decorator()
{
	delete _com;
}
void Decorator::Operation()
{
}
ConcreteDecorator::ConcreteDecorator(Component*com):Decorator(com)
{
}
ConcreteDecorator::~ConcreteDecorator()
{
}
void ConcreteDecorator::AddedBehavior()
{
	std::cout<<"ConcreteDecorator::AddedBehacior...."<<std::endl;
}
void ConcreteDecorator::Operation()
{
	_com->Operation();
	this->AddedBehavior();
}

//main.cpp
#include "Decorator.h"
#include <iostream>
using namespace std;
int main(int argc,char* argv[])
{
	Component* com = new ConcreteComponent();
	Decorator* dec = new ConcreteDecorator(com);
	dec->Operation();
	delete dec;
	return 0;
}
总结：

Decorate pattern 将类的核心职责和装饰功能区分开，并且也能去除了重复的装饰逻辑。

Composite Pattern

问题：

递归构建树状的组合结构。

方案：

在这里插入图片描述Component 表示枝节点，管理叶节点；
Leaf 表示的是叶节点；

Code:
//Component.h
#ifndef _COMPONENT_H_
#define _COMPONENT_H_
class Component
{
public:
Component();
virtual ~Component();
public:
virtual void Operation() = 0;
virtual void Add(const Component& );
virtual void Remove(const Component& );
virtual Component* GetChild(int );
protected:
private:
};
#endif //~_COMPONENT_H_

//Component.cpp
#include "Component.h"
Component::Component()
{
}
Component::~Component()
{
}
void Component::Add(const Component& com)
{
}
Component* Component::GetChild(int index)
{
return 0;
}
void Component::Remove(const Component& com)
{
}

//Composite.h
#ifndef _COMPOSITE_H_
#define _COMPOSITE_H_
#include "Component.h"
#include <vector>
using namespace std;
class Composite:public Component
{
public:
Composite();
~Composite();
public:
void Operation();
void Add(Component* com);
void Remove(Component* com);
Component* GetChild(int index);
protected:
private:
vector<Component*> comVec;
};
#endif //~_COMPOSITE_H_

//Composite.cpp
#include "Composite.h"
#include "Component.h"
#define NULL 0
//define NULL POINTOR
Composite::Composite()
{
//vector<Component*>::iterator itend = comVec.begin();
}
Composite::~Composite()
{
}
void Composite::Operation()
{
vector<Component*>::iterator comIter = comVec.begin();
for (;comIter != comVec.end();comIter++)
{
(*comIter)->Operation();
}
}
void Composite::Add(Component* com)
{
comVec.push_back(com);
}
void Composite::Remove(Component* com)
{
comVec.erase(&com);
}
Component* Composite::GetChild(int index)
{
return comVec[index];
}

//Leaf.h
#ifndef _LEAF_H_
#define _LEAF_H_
#include "Component.h"
class Leaf:public Component
{
	public:
	Leaf();
	~Leaf();
	void Operation();
	protected:
	private:
};
#endif //~_LEAF_H_//Leaf.h

//Leaf.cpp
#include "Leaf.h"
#include <iostream>
using namespace std;
Leaf::Leaf()
{
}
Leaf::~Leaf()
{
}
void Leaf::Operation()
{
	cout<<"Leaf operation....."<<endl;
}

//main.cpp
#include "Component.h"
#include "Composite.h"
#include "Leaf.h"
#include <iostream>
using namespace std;
int main(int argc,char* argv[])
{
	Leaf* l = new Leaf();
	l->Operation();
	Composite* com = new Composite();
	com->Add(l);
	com->Operation();
	Component* ll = com->GetChild(0);
	ll->Operation();
	return 0;
}
总结：

Composite 模式在实现中有一个问题就是要提供对于子节点(Leaf)的管理策略,这里使用的是 STL 中的 vector,可以提供其他的实现方式,如数组、链表、Hash 表等。

Proxy Pattern

方案：

在这里插入图片描述

应用场景：

远程代理：为网络上的对象创建一个局部的本地代理；
虚代理：需要创建开销非常大的对象时，代理存放构造时间很长的真实对象；
安全代理：根据真实对象的不同操作权限，让代理完成相应权限控制范围内的操作；
智能指引：当真实对象被调用时，代理完成另外一些任务。比如智能指针内部维护的引用计数，当计数为零则释放对象资源；

大裤衩儿
关注
  • 0
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Adaptor&Decorator&Facade模式分析
jamesjxin的专栏
06-09 871
本文目的在于对比分析Adaptor,Decorator,Facade这三种设计模式的差异，加深对这几种设计模式的理解。 模式 说明 Adaptor 把接口A的具体实现转换成对接口B的实现，以实现对B接口调用的客户能使用A提供的功能。 Decorator
设计模式实战：组合型模式Composite，Adapter
weixin_34029949的博客
07-23 71
考虑用网页的形式表现一个如Adapter Report的测试报告：一个报表由2部分组成，一是封面，一是对各个测试项目及其结果的描述。每个测试项目分为项目名称，测试数量，测试条件，测试结果，结果描述等几项。其中测试数量和测试条件可能不会出现，可能出现，结果描述有时需要以表格或列表的形式列出详细的数据，如果是以表格的形式，则有可能有是多级表头，每个表格的列数并不固定。总的来说，这个报表是树型结构，如下...
设计模式之adapter bridge模式
Innost的专栏
07-17 4861
<br />先说adapter模式<br />adapter中文为适配器模式，目的和想法很简单，就是一种封装，只不过这种封装是为了从接口A到达接口B，啥个意思呢，A已经提供功能了，但是另外一个东西只能使用B的接口，所以得弄一个东西将A转换成B接口，这个转换器就是adpater。从这个描述可以看到，我们实际上有三个东西。<br />  A----adapter-----B。其中A叫adaptee，B叫target。<br />怎么实现呢？通常有2种方法：<br />adapter---继承A,B，这样使用B的
构建型设计模式—adapter(适配器模式)/bridge(桥接模式)/decorator(装饰者模式)
zhangCheng的博客
10-18 247
一、构建型设计模式的作用 关注点在于如何将多个类或对象,整体布局成一个更强大的结构 二、adapter(适配器模式) (1)、思想 当原接口不能处理某种数据的时候,就交给一个适配器去处理(类似于转接头原理)。 适配器根据不同的参数,来确定用哪一个扩展的对象方法(哪一个插卡连接)来处理数据。 重点就在于根据参数的不同,选择不同的处理方式,在客户端要看不出内部实现, 逻辑全在适配器里判断。 (2)、步骤 1. 声明原接口，创建接口方法。 2. 声明原接口实现类,持有适配器,,重写接口方法,方法里面根据
设计模式之Adapter模式
qq_35082338的博客
03-21 193
## 什么时候使用适配器模式 ##一定有人看到适配器模式就会有疑问“如果某个方法就是我们所需要的方法，那么我们直接调用不就可以了，为什么会考虑用适配器模式呢”。如果用适配器模式，那么我们在什么时候使用适配器模式呢？很大程度上，我们都不会从零开始编程，经常会用到现有的类。特别是现有的类已经被应用，很少有BUG，我们很愿意复用这些类。Adapter模式会对现有的类进行适配，生成新的类，并创建我们所需要...
Darren设计之美,设计模式应该怎么学习
04-21
2. 结构型模式：这些模式关注如何将类和对象组合成更大的结构，如适配器模式（Adapter）、装饰器模式（Decorator）、代理模式（Proxy）、桥接模式（Bridge）、组合模式（Composite）、外观模式（Facade）和享元模式...
Java设计模式之禅
04-07
《Java设计模式之禅》是一本深入浅出讲解设计模式的书籍，书中不仅包含23种经典设计模式的案例，还详细介绍了设计模式背后的思想和原则，适合初学者以及对设计模式有一定了解的程序员阅读。本书旨在帮助读者理解如何...
复习提纲之设计模式总结1
08-03
设计模式是一种在软件设计中广泛使用的可重用解决方案，它针对特定问题提供了经过验证的设计蓝图。在编程领域，设计模式可以提升代码的可读性、可维护...理解并熟练运用设计模式，是成为一名优秀程序员的重要能力之一。
设计模式原理与应用之结构型模式.pptx
最新发布
09-28
本篇主要讨论了七种结构型模式：Adapter、Bridge、Composite、Decorator、Façade、Flyweight和Proxy。 1. **Adapter模式**： - 适配器模式旨在解决接口不兼容的问题，使得原本无法协同工作的类能够一起工作。它...
PHP设计模式之结构模式的深入解析
12-19
结构模式是设计模式中的一个重要类别，主要关注如何组织类和对象来构成更大的结构，以便于系统的扩展和维护。以下是对PHP设计模式中结构模式的深入解析。 1. **适配器模式（Adapter）**： 适配器模式允许两个不...
设计模式笔记(4 ADAPTER & BRIDGE)
不亦快斋
03-14 2156
ADAPTER(适配器)适用性：想使用一个已经存在的类，而它的接口不符合要求。想创建一个可以复用的类，该类可以与其他不相关的类或者不可预见的类协同工作。结构：适配器使用多重继承对一个接口和另一个接口适配。（这和proxy模式可以比较一下）多重继承的更好说法也许是组合。具体如何实现要看适配器的实现复杂程度。思考：被适配的类可能是多样的，但是应该完成相同的功能，适配器类只是用来匹配接口，并不是用来大规
设计模式(bridge和adapter)
ID-wind
09-28 486
关于设计模式部分，代码部分摘抄书上的。编写代码过程中，能更好的理解设计模式所带来的强大之处。 以博文形式记录，方便学习。适配器模式（Adapter）：将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。 适配器模式有两种实现方式 类适配器//Adapter.h #ifndef _ADAPTER_H_ #define _ADAP
设计模式之桥接模式Bridge、State模式、Adapter模式、Mediator模式、Facade模式简介
mulinsen77的博客
11-21 467
继承关系要慎用，因为继承意味着高耦合，子类与父类之间的耦合度极高，而我们设计的时候强调的是高内聚，低耦合。 桥接模式（Bridge)是一种结构型设计模式。Bridge模式基于类的最小设计原则，通过使用封装、聚合及继承等行为让不同的类承担不同的职责。它的主要特点是把抽象(Abstraction)与行为实现(Implementation)分离开来，从而可以保持各部分的独立性以及应对他们的功能扩展。 B...
设计模式（bridge模式，Adapter模式，Observe模式，Template模式）
book_karlzhouzhi的专栏
08-25 563
android中读取位图bitmap时，分给虚拟机图片的堆栈8M的大小，很容易发生OutOfMemory异常 1， bridge模式：将抽象和实现分离出来。 它可以解决继承的缺点：如果继承层次很多，并且某一个方法在多层的类中可能出现变化，或者说这个方法不确定，如果某一个继承层次中的类想修改这个方法，就做不到。 因为这样可能对它的子类有影响。 这个时候就可以使用bridge模式，将这
结构型模式：Decorator模式,Composite模式,proxy模式
smilestone322的专栏
12-04 918
Decorator模式： 在面向对象的设计和开发过程中，可能会经常遇到以下的情况；我们需要为一个已经定义好的类添加新的职责，通过情况我们会给定义一个新类继承自定义好的类，通过继承的方式解决这样的情况会带来系统的复杂性，因为继承的深度会变得很深。而Decorator提供了一种给类增加职责的方法，不是通过继承实现，而是通过组合。 Decorator装饰模式是一种结构型模式，它主要是解决：”过度地使
Java设计模式（三）Adapter(适配器),Bridge(桥接)
四色专栏
11-05 1537
 结构模式（－）Adapter(适配器)将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。 Adapter分为2种:类适配器和对象适配器。Adapter和Adaptee之间是is-a关系的时候，属于类适配器，Adapter和Adaptee之间是has-a关系的时候，属于对象适配器。 
几种结构型的设计模式概析【上】——Bridge模式，Adapter模式，Decorator模式【C++实现】
酋长Clement ——成长之路
03-28 1143
Bridge模式适用于客户需求经常变化时的类的抽象和封装情况。在OO型的程序设计中，用户的需求变化，意味着类的重新抽象和封装，当用户的需求变化十分频繁时，类的重新抽象和封装工作也就颇为频繁，如此以来，将会增加和修改很多类。这对程序开发人员来说，无非是最大的痛苦。Bridge模式就是为此种情况而生，它将类的抽象和实现分为完全独立的两部分，然后通过聚合使两者又保持一定的联系。这与传统的抽象基类之后再继承子类的作用如出一辙，但却少了增加新类的环节，由此以来，程序员维护的类的数量就减少，代码的可读性也大大增加，最重
Builder,Adapter,Decorator,Bridge 模式
凤凰的专栏
05-28 565
Builder,Adapter,Decorator,Bridge 模式既有不同点也有相似处 除了Builder是创建型外其它都是属于结构型模式而且基本思想是 面向接口,多用组合代替继承 Builder:将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示. Adapter:将两个不兼容的类纠合在一起使用 Decorat
Composite和Decorater模式联系和区别
自由理想的足迹
09-12 1845
组合模式使用情景：为了给外部一个多个子类组合而成的对象时候，为了分离耦合和提供拓展性可以采用组合模式-得到树形结构，而不是拓展性不好的管理器模式。 装饰模式使用情景：为了方便修改装饰已经存在的类，保存现有类的引用，提供更可拓展的方案，而不是继承现有的类；装饰模式在需要被装饰体（游戏角色）身上经常使用，如果不继承被装饰（角色）类，而是独立做一个Plugin只是保存被装饰（角色）类的引用也可以做到，
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值