结构型模式:让类和类进行组合,获得更大的结构。
代理模式
代理模式的定义: 为其他对象提供一种代理以控制对这个对象的访问。在某些情况下,一个对象不适合或者不能直接引用另一个对象,而代理对象可以在客户端和目标对象之间起到中介的作用。
subject(抽象主题角色):真实主题与代理主题的共同接口。
RealSubject(真实主题角色):定义了代理角色所代表的真实对象。
Proxy(代理主题角色):含有对真实主题角色的引用,代理角色通常在将客户端调用传递给真是主题对象之前或者之后执行某些操作,而不是单纯返回真实的对象。
案例:
#define _CRT_SECURE_NO_WARNINGS
#include<iostream>
#include<string>
using namespace std;
//商品类
class Goods{
public:
Goods(bool IsReal, string GoodsName) :m_IsReal(IsReal), m_GoodsName(GoodsName){}
bool getIsReal(){
return m_IsReal;
}
string getGoodsName(){
return m_GoodsName;
}
private:
bool m_IsReal; //商品真假
string m_GoodsName; //商品名称
};
//购物抽象
class AbstractShopping{
public:
virtual void BuyGoods(Goods*) = 0;
};
//韩国购物
class KoreaShopping : public AbstractShopping{
public:
virtual void BuyGoods(Goods* goods){
cout << "在韩国购买" << goods->getGoodsName() << endl;
}
};
//美国购物
class AmericanShopping : public AbstractShopping{
public:
virtual void BuyGoods(Goods* goods){
cout << "在美国购买" << goods->getGoodsName() << endl;
}
};
//非洲购物
class AfricanShopping : public AbstractShopping{
public:
virtual void BuyGoods(Goods* goods){
cout << "在非洲购买" << goods->getGoodsName() << endl;
}
};
//自己购物
void test01(){
AbstractShopping* shopping = NULL;
//去美国买啤酒
Goods* bear = new Goods(true, "啤酒");
shopping = new AmericanShopping;
shopping->BuyGoods(bear);
delete bear;
delete shopping;
//去韩国买化妆品
Goods* cosmetics = new Goods(true, "化妆品");
shopping = new KoreaShopping;
shopping->BuyGoods(cosmetics);
delete cosmetics;
delete shopping;
Goods* ivory = new Goods(true, "象牙");
shopping = new AfricanShopping;
shopping->BuyGoods(ivory);
delete ivory;
delete shopping;
}
//现在我不想自己去购物了 自己需要花费路费 还有自己办理货品海关检查 自己辨别商品真伪
//海外代购 帮助检查商品真伪 海关检查
class OverseasShopping : public AbstractShopping{
public:
OverseasShopping(AbstractShopping* mode){
pShoppingMode = mode; //购物模式 去韩国买 还是去美国买 还是去非洲买
}
virtual void BuyGoods(Goods* goods){
if (GoodsIsReal(goods)){ //如果产品是真的
CheckGoods(); //海关检查
pShoppingMode->BuyGoods(goods);
}
else{
cout << goods->getGoodsName() << "是假商品,放弃购买!" << endl;
}
delete goods;
}
//辨别商品真伪
bool GoodsIsReal(Goods* goods){
cout << "海外代理检查 "<< goods->getGoodsName() << "货品真伪" << endl;
return goods->getIsReal();
}
void CheckGoods(){
cout << "海外代理商品海关检查" << endl;
}
~OverseasShopping(){
if (NULL != pShoppingMode){
delete pShoppingMode;
}
}
private:
AbstractShopping* pShoppingMode;
};
void test02(){
AbstractShopping* proxy = NULL;
//创建一个去韩国购物的代理
proxy = new OverseasShopping(new KoreaShopping);
proxy->BuyGoods(new Goods(true,"化妆品"));
delete proxy;
cout << "-----------------------" << endl;
//创建一个去美国买啤酒的代理
proxy = new OverseasShopping(new AmericanShopping);
proxy->BuyGoods(new Goods(false, "啤酒"));
delete proxy;
cout << "-----------------------" << endl;
//创建一个去非洲买啤象牙的代理
proxy = new OverseasShopping(new AfricanShopping);
proxy->BuyGoods(new Goods(true, "象牙"));
delete proxy;
}
int main(){
//test01();
test02();
return EXIT_SUCCESS;
}
代理模式的优缺点及适用场景
优点:
(1)能够协调调用者和被调用者,在一定程度上降低了系统的耦合度。
(2)客户端可以针对抽象主题角色进行编程,增加和更换代理类无须修改源代码,符合开闭原则,系统具有较好的灵活性和可扩展性。
缺点:
代理实现较为复杂。
适用场景:
为其他对象提供一种代理以控制对这个对象的访问。
外观模式
根据迪米特法则,如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用。
Facade模式也叫外观模式,是由GoF提出的23种设计模式中的一种。Facade模式为一组具有类似功能的类群,比如类库,子系统等等,提供一个一致的简单的界面。这个一致的简单的界面被称作facade。
Facade(外观角色):为调用方, 定义简单的调用接口。
SubSystem(子系统角色):功能提供者。指提供功能的类群(模块或子系统) 。
#define _CRT_SECURE_NO_WARNINGS
#include<iostream>
using namespace std;
/*
外观模式就是将复杂的子类系统抽象到同一个的接口进行管理
,外界只需要通过此接口与子类系统进行交互,而不必要直接与复杂的子类
系统进行交互
*/
//子系统1
class SubSystem1{
public:
void run(){
cout << "子系统一运行..." << endl;
}
};
//子系统2
class SubSystem2{
public:
void run(){
cout << "子系统二运行..." << endl;
}
};
//子系统3
class SubSystem3{
public:
void run(){
cout << "子系统三运行..." << endl;
}
};
//子系统4
class SubSystem4{
public:
void run(){
cout << "子系统四运行..." << endl;
}
};
//外观类
class Facede{
public:
Facede(){
pSystem1 = new SubSystem1;
pSystem2 = new SubSystem2;
pSystem3 = new SubSystem3;
pSystem4 = new SubSystem4;
}
void runSystem(){
pSystem1->run();
pSystem2->run();
pSystem3->run();
pSystem4->run();
}
private:
SubSystem1* pSystem1;
SubSystem2* pSystem2;
SubSystem3* pSystem3;
SubSystem4* pSystem4;
};
void test01(){
Facede* facede = new Facede;
facede->runSystem();
}
int main(){
test01();
return EXIT_SUCCESS;
}
外观模式的优缺点及适用场景
优点:
(1)它对客户端屏蔽了子系统组件,减少了客户端所需处理的对象数目,并使得子系统使用起来更加容易。通过引入外观模式,客户端代码将变得很简单,与之关联的对象也很少。
(2)它实现了子系统与客户端之间的松耦合关系,这使得子系统的变化不会影响到调用它的客户端,只需要调整外观类即可。
(3)一个子系统的修改对其他子系统没有任何影响。
缺点:
(1)不能很好地限制客户端直接使用子系统类,如果对客户端访问子系统类做太多的限制则减少了可变性和灵活性。
(2)如果设计不当,增加新的子系统可能需要修改外观类的源代码,违背了开闭原则。
适用场景:
(1) 复杂系统需要简单入口使用。
(2) 客户端程序与多个子系统之间存在很大的依赖性。
适配器模式
将一个类的接口转换成客户希望的另外一个接口。使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
Target(目标抽象类):目标抽象类定义客户所需接口,可以是一个抽象类或接口,也可以是具体类。
Adapter(适配器类):适配器可以调用另一个接口,作为一个转换器,对Adaptee 和 Target 进行适配,适配器类是适配器模式的核心,在对象适配器中,它通过 继承 Target 并关联一个 Adaptee 对象使二者产生联系。
Adaptee(适配者类):适配者即被适配的角色,它定义了一个已经存在的接口, 这个接口需要适配,适配者类一般是一个具体类,包含了客户希望使用的业务方 法,在某些情况下可能没有适配者类的源代码。
根据对象适配器模式结构图,在对象适配器中,客户端需要调用 request() 方法,而适配者类 Adaptee 没有该方法,但是它所提供的 specificRequest() 方法却是客户端所需要的。为了使客户端能够使用适配者类,需要提供一个包装 类 Adapter,即适配器类。这个包装类包装了一个适配者的实例,从而将客户端
与适配者衔接起来,在适配器的 request()方法中调用适配者 specificRequest() 方法。因为适配器类与适配者类是关联关系(也可称之为委派关系),所以这种 适配器模式称为对象适配器模式。
#define _CRT_SECURE_NO_WARNINGS
#include<iostream>
#include<list>
using namespace std;
//A需要治疗感冒
class PersonA{
public:
void treatGanmao(){
cout << "A需要治疗感冒!" << endl;
}
};
//B需要治疗头疼
class PersonB{
public:
void treatTouteng(){
cout << "B需要治疗头疼!" << endl;
}
};
//C需要治疗痔疮
class PersonC{
public:
void treatZhichuang(){
cout << "C需要治疗痔疮!" << endl;
}
};
//目标接口
class Target{
public:
virtual void treat() = 0;
};
//将PersonA的treatGanmao接口适配成treat
class AdapterPersonA : public Target{
public:
AdapterPersonA(){
pPerson = new PersonA;
}
virtual void treat(){
pPerson->treatGanmao();
}
private:
PersonA* pPerson;
};
//将PersonB的treatTouteng接口适配成treat
class AdapterPersonB : public Target{
public:
AdapterPersonB(){
pPerson = new PersonB;
}
virtual void treat(){
pPerson->treatTouteng();
}
private:
PersonB* pPerson;
};
//将PersonC的treatZhichuang接口适配成treat
class AdapterPersonC : public Target{
public:
AdapterPersonC(){
pPerson = new PersonC;
}
virtual void treat(){
pPerson->treatZhichuang();
}
private:
PersonC* pPerson;
};
//医生
class Doctor{
public:
void addPatient(Target* patient){
m_list.push_back(patient);
}
void startTreat(){
for (list<Target*>::iterator it = m_list.begin(); it != m_list.end();it ++){
(*it)->treat();
}
}
private:
list<Target*> m_list;
};
//测试
void test01(){
//创建三个病人
Target* patient1 = new AdapterPersonA;
Target* patient2 = new AdapterPersonB;
Target* patient3 = new AdapterPersonC;
//创建医生
Doctor* doctor = new Doctor;
doctor->addPatient(patient1);
doctor->addPatient(patient2);
doctor->addPatient(patient3);
//医生逐个对病人进行治疗
doctor->startTreat();
}
int main(){
test01();
return EXIT_SUCCESS;
}
适配器模式优缺点及适用场景
优点:
(1)将目标类和适配者类解耦,通过引入一个适配器类来重用现有的适配者类,无须修改原有结构。
(2)增加了类的透明性和复用性,将具体的业务实现过程封装在适配者类中,对于客户端类而言是透明的,而且提高了适配者的复用性,同一个适配者类可以在多个不同的系统中复用。
(3)灵活性和扩展性都非常好,可以很方便地更换适配器,也可以在不修改原有代码的基础上增加新的适配器类,完全符合“开闭原则”。
缺点:
适配器中置换适配者类的某些方法比较麻烦。
适应场景:
(1) 系统需要使用一些现有的类,而这些类的接口(如方法名)不符合系统的需要,甚至没有这些类的源代码。
(2) 想创建一个可以重复使用的类,用于与一些彼此之间没有太大关联的一些类,包括一些可能在将来引进的类一起工作。
装饰模式
装饰模式又叫包装模式,通过一种对客户端透明的方式来扩展对象功能,是继承关系的一种替代。
装饰模式就是把要附加的功能分别放在单独的类中,并让这个类包含它要装饰的对象,当需要执行时,客户端就可以有选择的、按顺序的使用装饰功能包装对象。
Component(抽象构件):它是具体构件和抽象装饰类的共同父类,声明了在具体构件中实现的业务方法,它的引入可以使客户端以一致的方式处理未被装饰的对象以及装饰之后的对象,实现客户端的透明操作。
ConcreteComponent(具体构件):它是抽象构件类的子类,用于定义具体的构件对象,实现了在抽象构件中声明的方法,装饰器可以给它增加额外的职责(方法)。
Decorator(抽象装饰类):它也是抽象构件类的子类,用于给具体构件增加职责,但是具体职责在其子类中实现。它维护一个指向抽象构件对象的引用,通过该引用可以调用装饰之前构件对象的方法,并通过其子类扩展该方法,以达到装饰的目的。
ConcreteDecorator(具体装饰类):它是抽象装饰类的子类,负责向构件添加新的职责。每一个具体装饰类都定义了一些新的行为,它可以调用在抽象装饰类中定义的方法,并可以增加新的方法用以扩充对象的行为。
#define _CRT_SECURE_NO_WARNINGS
#include <iostream>
using namespace std;
//一般情况下 用继承实现类的功能拓展
//装饰模式 可以动态给一个类增加功能
//抽象英雄
class AbstractHero{
public:
virtual void ShowStatus() = 0;
public:
int mHp;
int mMp;
int mAt;
int mDf;
};
//具体英雄
class HeroA : public AbstractHero{
public:
HeroA(){
mHp= 0 ;
mMp= 0 ;
mAt= 0 ;
mDf= 0 ;
}
virtual void ShowStatus(){
cout << "血量:" << mHp << endl;
cout << "魔法:" << mMp << endl;
cout << "攻击:" << mAt << endl;
cout << "防御:" << mDf << endl;
}
};
//英雄穿上某个装饰物 那么他还是个英雄
class AbstractEquipment : public AbstractHero{
public:
AbstractEquipment(AbstractHero* hero){
this->pHero = hero;
}
virtual void ShowStatus(){}
public:
AbstractHero* pHero;
};
//狂徒
class KuangtuEquipment : public AbstractEquipment{
public:
KuangtuEquipment(AbstractHero* hero) :AbstractEquipment(hero){}
//增加额外功能
void AddKuangtu(){
cout << "英雄穿上狂徒之后..." << endl;
this->mHp = this->pHero->mHp;
this->mMp = this->pHero->mMp;
this->mAt = this->pHero->mAt;
this->mDf = this->pHero->mDf + 30;
delete this->pHero;
}
virtual void ShowStatus(){
AddKuangtu(); //额外增加功能
cout << "血量:" << mHp << endl;
cout << "魔法:" << mMp << endl;
cout << "攻击:" << mAt << endl;
cout << "防御:" << mDf << endl;
}
};
//无尽之刃
class WujinzhiKnife : public AbstractEquipment{
public:
WujinzhiKnife(AbstractHero* hero) :AbstractEquipment(hero){}
//增加额外功能
void AddKuangtu(){
cout << "英雄装备无尽之刃之后..." << endl;
this->mHp = this->pHero->mHp;
this->mMp = this->pHero->mMp;
this->mAt = this->pHero->mAt + 80;
this->mDf = this->pHero->mDf;
delete this->pHero;
}
virtual void ShowStatus(){
AddKuangtu();
cout << "血量:" << mHp << endl;
cout << "魔法:" << mMp << endl;
cout << "攻击:" << mAt << endl;
cout << "防御:" << mDf << endl;
}
};
void test01(){
AbstractHero* hero = new HeroA;
hero->ShowStatus();
cout << "---------------" << endl;
//给裸奔的英雄穿上衣服
hero = new KuangtuEquipment(hero);
hero->ShowStatus();
cout << "---------------" << endl;
//给英雄装备武器
hero = new WujinzhiKnife(hero);
hero->ShowStatus();
}
int main(void){
test01();
return 0;
}
装饰模式的优缺点及适用场景
优点:
(1)对于扩展一个对象的功能,装饰模式比继承更加灵活性,不会导致类的个数急剧增加。
(2)可以通过一种动态的方式来扩展一个对象的功能,从而实现不同的行为。
(3)可以对一个对象进行多次装饰。
(4)具体构件类与具体装饰类可以独立变化,用户可以根据需要增加新的具体构件类和具体装饰类,原有类库代码无须改变,符合“开闭原则”。
缺点:
使用装饰模式进行系统设计时将产生很多小对象,大量小对象的产生势必会占用更多的系统资源,影响程序的性能。
适用场景:
(1) 动态、透明的方式给单个对象添加职责。
(2) 当不能采用继承的方式对系统进行扩展或者采用继承不利于系统扩展和维护时可以使用装饰模式。
装饰器模式关注于在一个对象上动态的添加方法,然而代理模式关注于控制对对象的访问。换句话说,用代理模式,代理类(proxy class)可以对它的客户隐藏一个对象的具体信息。因此,当使用代理模式的时候,我们常常在一个代理类中创建一个对象的实例。并且,当我们使用装饰器模式的时候,我们通常的做法是将原始对象作为一个参数传给装饰者的构造器。