写在前面：感谢GeekBand提供这样好的学习机会，让我在繁忙的工作之余可以学习巩固c++知识。以下是边学边记的一些扩展点。分享给大家。
这里更要感谢李建忠老师，讲的很好。这里记录的来自他的课件，很不错。
对象性能模式
面向对象很好地解决了“抽象”的问题，但是会付出一定的代价（虚函数和继承）。对于通常情况来说，面向对象的成本都可以被忽略。但是某些特殊情况中，需要考虑这个成本。
单件模式
使用动机
- 必须保证一些特殊的类在系统中只有一个实例，以确保逻辑的正确性和效率。比如数据层，网络层。
- 绕过常规的构造器，提供一种机制来保证一个类只有一个实例，以解决性能问题。（工厂模式绕过构造器是要解决紧耦合的问题。）
- 有必要只提供一个唯一的实例，不让有“能生成多个实例”的机会。
模式定义
保证一个类仅有一个实例，并提供一个该实例的全局访问点。--《设计模式》GoF
结构
单件模式
要点总结
- 单件模式中的实例构造器可以设置为protected以允许子类派生。
- 单件模式一般不要支持拷贝构造函数和Clone接口，因为这有可能导致出现多个对象实例而有悖初衷
- 注意多线程环境下安全的单件模式，注意对双检查锁的正确实现。
下面是实现方法，适用于不同的场合
Plan A：适用于单线程；
Plan B：多线程可以用，但是效率不太高。避免高并发的情况；
Plan C：双检查锁，一定会出问题，除非加volatile关键字（微软平台）；
Plan D：双检查锁，C++11之后可以用。
class Singleton{
private:
Singleton();
Singleton(const Singleton& other);
public:
static Singleton* getInstance();
static Singleton* m_instance;
};
Singleton* Singleton::m_instance=nullptr;
//Plan A：线程非安全版本
Singleton* Singleton::getInstance() {
if (m_instance == nullptr) {
m_instance = new Singleton();
}
return m_instance;
}
//Plan B：线程安全版本，但锁的代价过高
Singleton* Singleton::getInstance() {
Lock lock;
if (m_instance == nullptr) {
m_instance = new Singleton();
}
return m_instance;
}
//Plan C：双检查锁，但由于内存读写reorder不安全
Singleton* Singleton::getInstance() {
if(m_instance==nullptr){
Lock lock;
if (m_instance == nullptr) {
m_instance = new Singleton();
}
}
return m_instance;
}
//由于编译器的优化，会导致new的时候不按照规矩来
//规矩应该是先分配内存，然后执行构造器，最后赋值。
//Plan D：C++ 11版本之后的跨平台实现 (volatile)
std::atomic<Singleton*> Singleton::m_instance;
std::mutex Singleton::m_mutex;
Singleton* Singleton::getInstance() {
Singleton* tmp = m_instance.load(std::memory_order_relaxed);
std::atomic_thread_fence(std::memory_order_acquire);//获取内存fence
if (tmp == nullptr) {
std::lock_guard<std::mutex> lock(m_mutex);
tmp = m_instance.load(std::memory_order_relaxed);
if (tmp == nullptr) {
tmp = new Singleton;
std::atomic_thread_fence(std::memory_order_release);//释放内存fence
m_instance.store(tmp, std::memory_order_relaxed);
}
}
return tmp;
}
对象性能模式
享元模式
使用动机
- 在软件系统采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中，从而带来很高的运行时代价——主要指内存需求方面的代价
- 如何在避免大量细粒度对象问题同时，让外部客户程序仍然能透明底使用面向对象的方式来进行操作？
模式定义
运用共享技术有效地支持大量细粒度的对象--《设计模式》GoF
结构
享元模式
要点总结
- 面向对象很好地解决了抽象性的问题。但是作为一个运行在机器上的程序实体，我们需要考虑对象的代价问题。享元模式主要解决面向对象的代价问题，一般不触及面向对象的抽象性问题。
- 享元模式采用对象共享的做法来降低系统中对象的个数，从而降低细粒度对象给系统带来的内存压力。在具体实现方面，要注意对象状态的处理。
- 对象的数量太大从而导致对象内存开销加大——什么样的数量算大？这需要我们仔细的根据具体应用情况来评估，而不能凭空臆断。比如，用100,000个int对象（每个对象40byte）组成一种字体大约占用4M内存。如果应用程序觉得这个占用可观，那么就需要用享元模式来管理。以达到提升性能的目的。
下面是使用和不使用享元模式的情况，对比一下
//字体对象的量很大，而且写文章的时候经常需要来回调用
//这个没有用享元模式，运行时可能会带来比较大的开销。
class Font {
private:
//unique object key
string key;
//object state
//....
public:
Font(const string& key){
//...
}
};
//对于创建出来的字体需要妥善地管理
//推荐的创建方式，用字体池（工厂）管理
class FontFactory{
private:
map<string,Font* > fontPool;
public:
Font* GetFont(const string& key){
map<string,Font*>::iterator item=fontPool.find(key);
if(item!=footPool.end()){
return fontPool[key];
}
else{
Font* font = new Font(key);
fontPool[key]= font;
return font;
}
}
void clear(){
//...
}
};
状态变化模式
在组件构建过程中，某些对象的状态经常面临变化，如何对这些变化进行有效的管理？同时又维持高层模块的稳定？状态变化模式为这个问题提供了一种解决方案。
状态模式
使用动机
- 在软件构建过程中，某些对象的状态如果改变，其行为也会随之发生变化。比如文档处于只读状态，其支持的行为和读写状态支持的行为就可能完全不同。
- 如何在运行时根据对象的状态来透明地更改对象行为？而不会对对象操作和状态转化之间引入紧耦合？
模式定义
允许一个对象在其内部状态改变时改变他的行为。从而使对象看起来似乎修改了其行为。--《设计模式》GoF
结构
状态模式
要点总结
- State模式将所有与一个特定状态相关的行为都放入一个State的子类对象中，在对象状态切换时，切换相应对象；但同时维持State的接口，这样实现了具体操作与状态转换之间的解耦。
- 为不同的状态引入不同的对象使得状态转换变得更加明确，而且可以保证不会出现状态不一致的情况，因为转换是原子性的——即要么彻底转换过来，要么不转换。
- 如果State对象没有实例变量，那么各个上下文可以共享同一个State对象，从而节省对象开销。
下面是实现方法的举例，这个和策略模式有点像：用于松耦合地应对不断增长的业务类型（比如枚举+Switch / If-else）需求。
class NetworkState{
public:
NetworkState* pNext;
virtual void Operation1()=0;
virtual void Operation2()=0;
virtual void Operation3()=0;
virtual ~NetworkState(){}
};
class OpenState :public NetworkState{
static NetworkState* m_instance;
public:
static NetworkState* getInstance(){
if (m_instance == nullptr) {
m_instance = new OpenState();
}
return m_instance;
}
void Operation1(){
//**********
pNext = CloseState::getInstance();
}
void Operation2(){
//..........
pNext = ConnectState::getInstance();
}
void Operation3(){
//$$$$$$$$$$
pNext = OpenState::getInstance();
}
};
class CloseState:public NetworkState{ }
//...
class NetworkProcessor{
NetworkState* pState;
public:
NetworkProcessor(NetworkState* pState){
this->pState = pState;
}
void Operation1(){
//...
pState->Operation1();
pState = pState->pNext;
//...
}
void Operation2(){
//...
pState->Operation2();
pState = pState->pNext;
//...
}
void Operation3(){
//...
pState->Operation3();
pState = pState->pNext;
//...
}
};
备忘录模式
使用动机
- 在软件构建过程中，某些对象的状态在转换过程中，可能由于某种需要，要求程序能够回溯到对象之前处于某个点时的状态。如果使用一些公有接口来让其他对象得到对象的状态，便会暴露对象的细节实现。
- 如何实现对象状态的良好保存与恢复？但同时又不会因此而破坏对象本身的封装性。
模式定义
在不破坏封装性的前提下，捕获一个对象内部的状态，并在该对象之外保存这个状态。这样以后就可以将该对象恢复到原先保存的状态--《设计模式》GoF
结构
备忘录模式
要点总结
- 备忘录储存原发器对象的内部状态，在需要时回复原发器状态。
- 备忘录模式的核心是信息隐藏，即原发器需要向外界隐藏信息，保持其封装性。但同时又需要将状态保持到外界的备忘录中
- 由于现代语言运行时（如C#， Java等）都具有相当的对象序列化支持，因此往往采用效率较高、又较容易正确实现的序列化方案来实现备忘录模式。
下面是实现方法的举例,关键在于实现的思想
class Memento
{
string state;
//..
public:
Memento(const string & s) : state(s) {}
string getState() const { return state; }
void setState(const string & s) { state = s; }
};
class Originator
{
string state;
//....
public:
Originator() {}
Memento createMomento() {
Memento m(state);
return m;
}
void setMomento(const Memento & m) {
state = m.getState();
}
};
int main()
{
Originator orginator;
//捕获对象状态，存储到备忘录
Memento mem = orginator.createMomento();
//... 改变orginator状态
//从备忘录中恢复
orginator.setMomento(memento);
}
