| 九、外观模式（Facade
Pattern）
概述
想想我们小时候玩的四驱车，里面的构造很复杂，马达，舵机，电池组等等，而我们控制它却非常简单，只要打开电池开关，他就可以跑。我们其实不用知道它里面是如何工作，只要知道拨动开关它就可以工作就行了，这个开关其实就四驱车给我们的一个友好的组件，使得我们可以很方便的控制它。
外观模式其实定义了一个高层接口，该接口为子系统中的一组接口提供一个一致的界面，使得这一子系统更加容易使用。
类图和样例
在这个对象图中，出现了两个角色：
外观(Facade)角色：客户端可以调用这个角色的方法。此角色知晓相关的(一个或者多个)子系统的功能和责任。在正常情况下，本角色会将所有从客户端发来的请求委派到相应的子系统去。
子系统(subsystem)角色：可以同时有一个或者多个子系统。每一个子系统都不是一个单独的类，而是一个类的集合。每一个子系统都可以被客户端直接调用，或者被外观角色调用。子系统并不知道外观的存在，对于子系统而言，外观仅仅是另外一个客户端而已。
#include<iostream>
using namespace std;
class Scanner
{
public:
void Scan() { cout<<"词法分析"<<endl; }
};
class Parser
{
public:
void Parse() { cout<<"语法分析"<<endl; }
};
class GenMidCode
{
public:
void GenCode() { cout<<"产生中间代码"<<endl; }
};
class GenMachineCode
{
public:
void GenCode() { cout<<"产生机器码"<<endl;}
};
//高层接口 Fecade
class Compiler
{
public:
void Run()
{
Scanner scanner;
Parser parser;
GenMidCode genMidCode;
GenMachineCode genMacCode;
scanner.Scan();
parser.Parse();
genMidCode.GenCode();
genMacCode.GenCode();
}
};
//client
int main()
{
Compiler compiler;
compiler.Run();
return 0;
} |
要点
1．Facade模式对客户屏蔽了子系统组件，因而减少了客户处理的对象的数目并使得子系统使用起来更加方便。
2．Facade模式实现了子系统与客户之间的松耦合关系，而子系统内部的功能组件往往是紧耦合的。松耦合关系使得子系统的组件变化不会影响到它的客户。
3．如果应用需要，它并不限制它们使用子系统类。因此你可以在系统易用性与通用性之间选择。
4. 在外观模式中，通常只需要一个外观类，并且此外观类只有一个实例，换言之它是一个单例类。当然这并不意味着在整个系统里只能有一个外观类，而仅仅是说对每一个子系统只有一个外观类。或者说，如果一个系统有好几个子系统的话，每一个子系统有一个外观类，整个系统可以有数个外观类。
5. 外观模式的用意是为子系统提供一个集中化和简化的沟通管道，而不建议向子系统加入新的行为。
6. 外观模式注重的是简化接口，它更多的时候是从架构的层次去看整个系统，而并非单个类的层次。
适用性和优缺点
适用性
1．为一个复杂子系统提供一个简单接口。
2．提高子系统的独立性。
3．在层次化结构中，可以使用Facade模式定义系统中每一层的入口。
优点
1. 松散耦合
外观模式松散了客户端与子系统的耦合关系，让子系统内部的模块能更容易扩展和维护。即要点2.
2. 简单易用
外观模式让子系统更加易用，客户端不再需要了解子系统内部的实现，也不需要跟众多子系统内部的模块进行交互，只需要跟外观交互就可以了，相当于外观类为外部客户端使用子系统提供了一站式服务。
3. 更好的划分访问层次
通过合理使用Facade，可以帮助我们更好的划分访问的层次。有些方法是对系统外的，有些方法是系统内部使用的。把需要暴露给外部的功能集中到外观中，这样既方便客户端使用，也很好的隐藏了内部的细节。
缺点
过多的或者是不太合理的Facade也容易让人迷惑，到底是调用Facade好呢，还是直接调用模块好。
十、享元模式（Flyweight Pattern）
概述
想想我们编辑文档用的wps，文档里文字很多都是重复的，我们不可能为每一个出现的汉字都创建独立的空间，这样代价太大，最好的办法就是共享其中相同的部分，使得需要创建的对象降到最小，这个就是享元模式的核心，即运用共享技术有效地支持大量细粒度的对象。
享元对象能做到共享的关键是区分内蕴状态（Internal State）和外蕴状态（External
State）。内蕴状态是存储在享元对象内部并且不会随环境改变而改变。因此内蕴状态并可以共享。
外蕴状态是随环境改变而改变的、不可以共享的状态。享元对象的外蕴状态必须由客户端保存，并在享元对象被创建之后，在需要使用的时候再传入到享元对象内部。外蕴状态与内蕴状态是相互独立的。
类图与样例
抽象享元类（Flyweight）
它是所有具体享元类的超类。为这些类规定出需要实现的公共接口,那些需要外蕴状态(Exte的操作可以通过方法的参数传入。抽象享元的接口使得享元变得可能，但是并不强制子类实行共享，因此并非所有的享元对象都是可以共享的。
具体享元类(ConcreteFlyweight)
具体享元类实现了抽象享元类所规定的接口。如果有内蕴状态的话，必须负责为内蕴状态提供存储空间。享元对象的内蕴状态必须与对象所处的周围环境无关，从而使得享元对象可以在系统内共享。有时候具体享元类又称为单纯具体享元类，因为复合享元类是由单纯具体享元角色通过复合而成的。
不能共享的具体享元类(UnsharableFlyweight)
不能共享的享元类，又叫做复合享元类。一个复合享元对象是由多个单享元对象组成，这些组成的对象是可以共享的，但是复合享元类本身并不能共享。
享元工厂类(FlyweightFactoiy)
享元工厂类负责创建和管理享元对象。当一个客户端对象请求一个享元对象的时候，享元工厂需要检查系统中是否已经有一个符合要求的享元对象，如果已经有了，享元工厂角色就应当提供这个已有的享元对象；如果系统中没有适当的享元对象的话，享元工厂角色就应当创建一个新的合适的享元对象。
客户类(Client)
客户类需要自行存储所有享元对象的外蕴状态。
// CplusplusFlyweight.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <iostream>
#include <map>
using namespace std;
class Character
{
public:
virtual ~Character(){};
virtual void SetSize(int, int) = 0;
virtual void Display() = 0;
protected:
Character(){};
char m_chSymbol;
int m_nWeight;
int m_nHeight;
};
class CharacterA : public Character
{
public:
CharacterA();
virtual ~CharacterA();
void SetSize(int, int);
void Display();
};
CharacterA::CharacterA()
{
this->m_chSymbol = 'A';
this->m_nWeight = 100;
this->m_nHeight = 200;
}
CharacterA::~CharacterA()
{
}
void CharacterA::SetSize(int nWeight, int nHeight)
{
this->m_nWeight = nWeight;
this->m_nHeight = nHeight;
}
void CharacterA::Display()
{
cout << "CharacterA：" << m_chSymbol << "(" << m_nWeight << "," << m_nHeight << ")" << endl;
}
class CharacterB : public Character
{
public:
CharacterB();
virtual ~CharacterB();
void SetSize(int, int);
void Display();
};
CharacterB::CharacterB()
{
this->m_chSymbol = 'B';
this->m_nWeight = 100;
this->m_nHeight = 200;
}
CharacterB::~CharacterB()
{
}
void CharacterB::SetSize(int nWeight, int nHeight)
{
this->m_nWeight = nWeight;
this->m_nHeight = nHeight;
}
void CharacterB::Display()
{
cout << "CharacterB：" << m_chSymbol << "(" << m_nWeight << "," << m_nHeight << ")" << endl;
}
class CharacterFactory
{
public:
CharacterFactory();
virtual ~CharacterFactory();
Character* GetCharacter(char);
private:
std::map<char, Character*> m_mChar;
};
CharacterFactory::CharacterFactory()
{
m_mChar.insert(make_pair<char, Character*>('A', new CharacterA));
m_mChar.insert(make_pair<char, Character*>('B', new CharacterB));
}
CharacterFactory::~CharacterFactory()
{
}
Character* CharacterFactory::GetCharacter(char chIn)
{
map<char, Character*>::iterator it = m_mChar.find(chIn);
if(it != m_mChar.end())
{
return (Character*)it->second;
}
return NULL;
}
int _tmain(int argc, _TCHAR* argv[])
{
CharacterFactory* pFactory = new CharacterFactory;
//内蕴状态 存储在享元对象内部并且不会随环境改变而改变
Character* ch1 = pFactory->GetCharacter('A');
ch1->Display();
//外蕴状态 客户端保存
Character* ch2 = pFactory->GetCharacter('B');
ch2->SetSize(500, 800);
ch2->Display();
return 0;
}
|
要点
1、面向对象很好的解决了抽象性的问题，但是作为一个运行在机器中的程序实体，我们需要考虑对象的代价问题。Flyweight设计模式主要解决面向对象的代价问题，一般不触及面向对象的抽象性问题。
2、Flyweight采用对象共享的做法来降低系统中对象的个数，从而降低细粒度对象给系统带来的内存压力。在具体实现方面，要注意对象状态的处理。
3、享元模式的优点在于它大幅度地降低内存中对象的数量。但是，它做到这一点所付出的代价也是很高的：享元模式使得系统更加复杂。为了使对象可以共享，需要将一些状态外部化，这使得程序的逻辑复杂化。另外它将享元对象的状态外部化，而读取外部状态使得运行时间稍微变长。
适用性
当以下所有的条件都满足时，可以考虑使用享元模式：
1、一个系统有大量的对象。
2、这些对象耗费大量的内存。
3、这些对象的状态中的大部分都可以外部化。
4、这些对象可以按照内蕴状态分成很多的组，当把外蕴对象从对象中剔除时，每一个组都可以仅用一个对象代替。
5、软件系统不依赖于这些对象的身份，换言之，这些对象可以是不可分辨的。
满足以上的这些条件的系统可以使用享元对象。最后，使用享元模式需要维护一个记录了系统已有的所有享元的表，而这需要耗费资源。因此，应当在有足够多的享元实例可供共享时才值得使用享元模式。
优缺点
享元模式的优点在于它大幅度地降低内存中对象的数量。但是，它做到这一点所付出的代价也是很高的：
1、享元模式使得系统更加复杂。为了使对象可以共享，需要将一些状态外部化，这使得程序的逻辑复杂化。
2、享元模式将享元对象的状态外部化，而读取外部状态使得运行时间稍微变长。
十一、代理模式（Proxy Pattern）
概述
作为C++工程师，免不了要管理内存，内存管理也是C++中的难点，而智能指针采用引用计数的办法很方便的帮我们管理了内存的使用，极大方便了我们的工作效率。而智能指针的这种用法其实就是代理模式的一种，他帮我们控制了该对象的内存使用。
代理模式就是为其他对象提供一种代理来控制对这个对象的访问。
种类和用途
Proxy模式根据种类不同，效果也不尽相同：
1、远程（Remote）代理：为一个位于不同的地址空间的对象提供一个局域代表对象。这个不同的地址空间可以是在本机器中，也可是在另一台机器中。远程代理又叫做大使（Ambassador）。好处是系统可以将网络的细节隐藏起来，使得客户端不必考虑网络的存在。客户完全可以认为被代理的对象是局域的而不是远程的，而代理对象承担了大部份的网络通讯工作。由于客户可能没有意识到会启动一个耗费时间的远程调用，因此客户没有必要的思想准备。
2、虚拟（Virtual）代理：根据需要创建一个资源消耗较大的对象，使得此对象只在需要时才会被真正创建。使用虚拟代理模式的好处就是代理对象可以在必要的时候才将被代理的对象加载；代理可以对加载的过程加以必要的优化。当一个模块的加载十分耗费资源的情况下，虚拟代理的好处就非常明显。
3、Copy-on-Write代理：虚拟代理的一种。把复制（克隆）拖延到只有在客户端需要时，才真正采取行动。
4、保护（Protector Access）代理：控制对一个对象的访问，如果需要，可以给不同的用户提供不同级别的使用权限。保护代理的好处是它可以在运行时间对用户的有关权限进行检查，然后在核实后决定将调用传递给被代理的对象。
5、Cache代理：为某一个目标操作的结果提供临时的存储空间，以便多个客户端可以共享这些结果。
6、防火墙（Firewall）代理：保护目标，不让恶意用户接近。
7、同步化（Synchronization）代理：使几个用户能够同时使用一个对象而没有冲突。
8、智能引用（SmartReference）代理：当一个对象被引用时，提供一些额外的操作，比如将对此对象调用的次数记录下来等。
在所有种类的代理模式中，虚拟（Virtual）代理、远程（Remote）代理、智能引用代理（SmartReference
Proxy）和保护（Protector Access）代理是最为常见的代理模式。
类图和实例
代理模式所涉及的角色有：
抽象主题角色（Subject）：声明了真实主题和代理主题的共同接口，这样一来在任何使用真实主题的地方都可以使用代理主题。
代理主题（Proxy）角色：代理主题角色内部含有对真是主题的引用，从而可以在任何时候操作真实主题对象；代理主题角色提供一个与真实主题角色相同的接口，以便可以在任何时候都可以替代真实主体；控制真实主题的应用，负责在需要的时候创建真实主题对象（和删除真实主题对象）；代理角色通常在将客户端调用传递给真实的主题之前或之后，都要执行某个操作，而不是单纯的将调用传递给真实主题对象。
真实主题角色（RealSubject）角色：定义了代理角色所代表的真实对象。
这里给出一个C++中智能指针的例子，自己代码重新实现了下：
// TestProxy.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <assert.h>
#define KSAFE_DELETE(p) \
if (p) \
{ \
delete p; \
p = NULL; \
}
class KRefCount
{
public:
KRefCount():m_nCount(0){}
public:
void AddRef(){m_nCount++;}
int Release(){return --m_nCount;}
void Reset(){m_nCount=0;}
private:
int m_nCount;
};
template <typename T>
class KSmartPtr
{
public:
KSmartPtr(void)
: m_pData(NULL)
{
m_pReference = new KRefCount();
m_pReference->AddRef();
}
KSmartPtr(T* pValue)
: m_pData(pValue)
{
m_pReference = new KRefCount();
m_pReference->AddRef();
}
KSmartPtr(const KSmartPtr<T>& sp)
: m_pData(sp.m_pData)
, m_pReference(sp.m_pReference)
{
m_pReference->AddRef();
}
~KSmartPtr(void)
{
if (m_pReference && m_pReference->Release() == 0)
{
KSAFE_DELETE(m_pData);
KSAFE_DELETE(m_pReference);
}
}
inline T& operator*()
{
return *m_pData;
}
inline T* operator->()
{
return m_pData;
}
KSmartPtr<T>& operator=(const KSmartPtr<T>& sp)
{
if (this != &sp)
{
if (m_pReference && m_pReference->Release() == 0)
{
KSAFE_DELETE(m_pData);
KSAFE_DELETE(m_pReference);
}
m_pData = sp.m_pData;
m_pReference = sp.m_pReference;
m_pReference->AddRef();
}
return *this;
}
KSmartPtr<T>& operator=(T* pValue)
{
if (m_pReference && m_pReference->Release() == 0)
{
KSAFE_DELETE(m_pData);
KSAFE_DELETE(m_pReference);
}
m_pData = pValue;
m_pReference = new KRefCount;
m_pReference->AddRef();
return *this;
}
T* Get()
{
T* ptr = NULL;
ptr = m_pData;
return ptr;
}
void Attach(T* pObject)
{
if (m_pReference->Release() == 0)
{
KSAFE_DELETE(m_pData);
KSAFE_DELETE(m_pReference);
}
m_pData = pObject;
m_pReference = new KRefCount;
m_pReference->AddRef();
}
T* Detach()
{
T* ptr = NULL;
if (m_pData)
{
ptr = m_pData;
m_pData = NULL;
m_pReference->Reset();
}
return ptr;
}
private:
KRefCount* m_pReference;
T* m_pData;
}; |
与其他模式的区别
1)适配器模式Adapter
适配器Adapter为它所适配的对象提供了一个不同的接口。相反，代理提供了与它的实体相同的接口。然而，用于访问保护的代理可能会拒绝执行实体会执行的操作，因此，它的接口实际上可能只是实体接口的一个子集。
2) 装饰器模式Decorator
尽管Decorator的实现部分与代理相似，但Decorator的目的不一样。Decorator为对象添加一个或多个功能，而代理则控制对对象的访问。
总结
在软件系统中，加一个中间层是我们常用的解决方法，这方面Proxy模式给了我们很好的实现。
十二、责任链模式（Chain Of Responsibility Pattern）
概述：
辛辛苦苦了工作了一年，终于可以加薪了，向主管提交了加薪申请，主管一看不得了，自己职权不够，批不了，主管把申请上交总监，总监发现自己也批不了，申请到了总经理手中，总经理一看，小伙子口气不小了，有胆识敢申请，先来谈下心。预知后事如何，请看下回分解。
这就是典型的职责链模式，请求的处理形成了一条链，直到有一个对象处理请求。责任链模式是一种对象的行为模式。在责任链模式里，很多对象由每一个对象对其下家的引用而连接起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求，这使得系统可以在不影响客户端的情况下动态地重新组织链和分配责任。
类图与实例：
抽象处理者(Handler)角色：定义出一个处理请求的接口。如果需要，接口可以定义出一个方法，以设定和返回对下家的引用。这个角色通常由一个抽象类或接口实现。
具体处理者(ConcreteHandler)角色：具体处理者接到请求后，可以选择将请求处理掉，或者将请求传给下家。由于具体处理者持有对下家的引用，因此，如果需要，具体处理者可以访问下家。
样例：
#include <iostream>
#include <string>
using namespace std;
// 请求
class Request
{
public:
int m_nNumber;
};
// 管理者
class Manager
{
public:
Manager(string temp) { name = temp; }
void SetSuccessor(Manager* temp) { manager = temp; }
virtual void GetRequest(Request* request) = 0;
protected:
Manager* manager;
string name;
};
// 经理
class CommonManager : public Manager
{
public:
CommonManager(string strTemp) : Manager(strTemp) {}
virtual void GetRequest(Request* request);
};
void CommonManager::GetRequest(Request* request)
{
if (request->m_nNumber>=0 && request->m_nNumber<1000)
{
cout << name << " 处理了请求: " << request->m_nNumber << endl;
}
else
{
manager->GetRequest(request);
}
}
// 总监
class Majordomo : public Manager
{
public:
Majordomo(string strTemp) : Manager(strTemp) {}
virtual void GetRequest(Request* request);
};
void Majordomo::GetRequest(Request* request)
{
if (request->m_nNumber <= 5000)
{
cout << name << " 处理了请求: " << request->m_nNumber << endl;
}else
{
manager->GetRequest(request);
}
}
//总经理
class GeneralManager: public Manager
{
public:
GeneralManager(string name):Manager(name) {}
virtual void GetRequest(Request* request) //总经理可以处理所有请求
{
cout << name << " 处理了请求: " << request->m_nNumber << endl;
}
};
int main(){
Manager* common = new CommonManager("张经理");
Manager* major = new Majordomo("李总监");
GeneralManager* general = new GeneralManager("赵总");
common->SetSuccessor(major);
major->SetSuccessor(general);
Request* rq = new Request();
rq->m_nNumber = 999;
common->GetRequest(rq);
rq->m_nNumber = 4999;
common->GetRequest(rq);
rq->m_nNumber = 6999;
common->GetRequest(rq);
delete rq;
delete major;
delete common;
delete general;
return 0;
} |
要点与实现：
1.要注意的是：一个请求到链的最后可能也没有处理，所以一定要配置得当.
2.责任链模式并不创建责任链。责任链的创建必须由系统的其它部分创建出来。
3.责任链模式降低了请求的发送端和接收端之间的耦合，使多个对象都有机会处理这个请求。一个链可以是一条线，一个树，也可以是一个环。如下图所示，责任链是一个树结构的一部分。
|
