Some Design Pattern Ⅰ

情绝格调(fresmaster) — Sat, 10 Nov 2012 11:37:00 GMT

设计模式是关于形式化一些通用软件解决方案，为日常工程任务的讨论提供可供参考的通用框架。

一、Singleton单件模式 -创建型

《设计模式》中指出：Singleton模式的意图：保证一个类仅有一个实例，并提供一个访问它的全局访问点。

对一些类来说，只有一个实例是很重要的，怎么才能保证一个类只有一个实例并且这个实例易于被访问，首先，一个全局变量使得一个对象可以被访问，其次就是怎么保证只有一个实例，一个更好的方法时让类自身负责保存它的唯一实例，这个类可以保证没有其他实例可以被创建，并且他提供一个访问该实例的方法。这个就是Singleton模式。

当大量的类或者模块需要访问一个全局对象时，使用单间模式，

当这个唯一的实例应该是通过子类化可扩展的，并且客户应该无需更该改代码就能使用一个扩展的实例时，使用单间模式

一般结构:

类包含了指向它唯一实例的指针，定义一个Instance操作，允许客户访问它的唯一实例，Instance是一个类操作,通过提供一个static的接口来获取实例。

在设计游戏引擎时，对于纹理对象，如果类的每一个对象代表一个贴图对象，每次都调用函数从文件加载，势必造成性能下降、浪费内存。为了确保每个纹理加载一次，可以使用单件模式，让类自己负责它的创建，在访问函数中截取，使用Lazy Initiation，当私有的实例为空时，才进行创建，当然还要检查是否为空时要加锁，否则在竞争时会出现两个线程同时常见而让唯一的实例变成多个。

#ifndef _SINGLEONTEXTURE_H_
#define _SINGLEONTEXTURE_H_
class SingletonTexture{
public:
    static SingletonTexture* Instance();//全局访问点
protected:
   SingletonTexture();//自己负责创建
private:
    static SingletonTexture* m_instance;//保存自己的一个实例
};
#endif _SINGLEONTEXTURE_H_

#include 
#include "iostream"
using namespace std;
#include "Singleton.h"

SingletonTexture* SingletonTexture::m_instance = NULL;

SingletonTexture::SingletonTexture (){
    cout<<"SingletonTexture Created!"<<endl;
}
SingletonTexture* SingletonTexture::Instance (){
    if(m_instance == NULL){
        m_instance = new SingletonTexture();
        cout<<"m_instance == NULL"<<endl;
    }
    return m_instance;
}
int main(){
    SingletonTexture* ST = SingletonTexture::Instance ();
    system("pause");
    return 0;
}

这样只用创建一个非本地的静态对象就可以，但是具体的创建时间无法确定，解决办法就是把访问这个单件类的行为封装在一个函数内，当调用了这个函数时，才对单件类进行真正的创建，

class SingletonTexture{
public:
    SingletonTexture &Instance(){
        static SingletonTexture Obj;
        return Obj;
    }
private：
    SingletonTexture();
}；

对于第一种方法由于使用了类的静态成员，在内存中除了每个对象自己的数据成员以外，还会保留一份有关所有纹理对象信息列表，虽然使用了指针，但是由于没有类再从这个类继承下去，而且所有的对象都是一个类，相互之间没有资源释放的先后问题，就不会出现由于释放顺序出现悬空问题。但是由于同时对全部的纹理进行处理，可能会造成资源负荷过重，要建立一个日志；而第二种方法比较符合要求。

使用单件模式，而不简单的创建一个全局对象或者指针，首先通过简单的函数访问变量比在所有文件中声明extern简单，而且还可以控制变量初始化的时间；其次使用指针而不是用对象的话，可以通过C++对对象进行完全的访问，有更好的访问控制，例如对类每一次的访问进行监控；最后还可以创建singleton类然后再派生，可以再保证基类以及集成类的条件下，扩充基类。

二、Facade（外观）模式-对象结构型模式

《设计模式》中提到外观模式的意图是为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这个子系统更加容易使用。

实用性：

1.当你要为一个复杂子系统提供一个简单接口时，子系统往往要不断演化而变的复杂，大多数模式使用时都会产生更小的类，这使得子系统更具有重用性，也更容易对子系统进行定制，但是这也给那些不需要定制子系统的用户带来了一些使用上的困难，Facade可以提供一个简单的缺省视图，这一视图对大多数用户已经够了，而那些需要更多的定制的用户可以越过Facade这一层。

2.客户程序与抽象类的实现部分之间存在很大的依赖性。引入facade模式将这个子系统与客户以及其他的子系统分离，可以提高子系统的独立性和可移植性。

3.当你需要构建一个层次结构的子系统时，使用facade模式定义子系统的每层的入口点。如果子系统之间是相互依赖的，可以让他们通过facade进行通讯，从而简化了他们之间的依赖关系。

在设计具有一定复杂度的图形引擎时，它也具有扩展和变化的潜在可能，因此会使得整个系统之间的通信和相互依赖增加，导致系统复杂，灵活性降低，使用Facade模式将诸多复杂性和变化隐藏起来，高度封装图形引擎，使图形引擎这一子系统更加容易使用，同时由于这一子系统独一无二，应当作为一个Singleton。

为了使类之间的相关性（耦合性）达到最小，有必要使用Facade或管理器，当整个子系统需要进行大的改动或者是替换的时候，复杂的相关性就会产生问题，面向对象程序设计在类的范围内对实现改动进行了保护，但更广泛的改动保护需要一种新的范式，Facade模式在更大规模上解决了面向对象编程所保护的同类问题。实现Facade类的首要原则是：尽量避免子系统内部类对外的暴露。

结构：

#ifndef _FACADE_H_
#define _FACADE_H_
class SubSystemOne{
public:
    SubSystemOne(){
    }
    ~SubSystemOne(){
    }
    void Operator();

};

class SubSystemTwo{
public:
    SubSystemTwo(){
    }
    ~SubSystemTwo(){
    }
    void Operator();

};

class Facade{
public:
    Facade();
    ~Facade();
    void Operator();
private:
     SubSystemOne *so;
     SubSystemTwo *st;
};
#endif _FACADE_H_

#include "windows.h"
#include 
using namespace std;
#include "Facade.h"
void SubSystemOne::Operator(){
    cout<<"SubSystemOne Operator!"<<endl;
}
void SubSystemTwo::Operator(){
    cout<<"SubSystemTwo Operator!"<<endl;
}

Facade::Facade(){
    so = new SubSystemOne();
    st = new SubSystemTwo();
}
Facade::~Facade (){
    delete so;
    delete st;
}

void Facade::Operator (){
    so->Operator();
    st->Operator();
}
int main(){
    Facade * facade = new Facade();
    facade->Operator ();
    system("pause");
    return 0;

}

Facade模式在高层提供了一个统一的接口，更像是一个管理类，解藕了系统，设计模式中还有另外一种Mediator模式和Facade模式有类似地方，但是Mediator 主要目的是对象间的访问解耦。

三、State（状态）模式- 对象行为模式

《设计模式》中指出state 模式允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。

适用性

一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为；

一个操作中含有庞大的多分支的条件语句，且这些分支依赖于该对象的状态，这个状态通常用一个或者多个枚举常量表示。通常，有多个操作包含这一相同的条件结构。state模式将每一个条件分支放入一个独立的类中，使得你可以根据对象自身的情况将对象的状态作为一个对象，这一对象可以不依赖其他对象而独立变换。

在游戏中，程序员需要处理游戏状态而不断的实时追踪问题，状态在刚开始的时候通常是简单的枚举，其行为实现基于switch…case结构的选择，然后当状态的数量增大，维护一组switch…case语句会是一件异常困难并且出错率较高的事情。，而且状态逻辑与动作实现没有分离，动作的代码直接写在状态的逻辑中，将使系统的可扩展性和维护性性能变低。state模式将状态逻辑与动作实现分离开来，当一个操作中药维护大量的case分支语句，并且这些分支语句依赖于对象的状态，state模式将每一个分支都独立封装到独立的类中。

结构：

示例：

#ifndef _STATE_H_
#define _STATE_H_
class State;
class Context{
public:
    Context(State *ps);
    ~Context();
    void Request();
    void ChangeState(State *ps);
private:
    State *m_state;
};

class State{
public:
    State(){}
    virtual ~State(){}
    virtual void Handle(Context *context)=0;
};

class StateA : public State{
public:
    StateA(){}
    ~StateA(){}
   void Handle(Context *context);
};
class StateB : public State{
public:
    StateB(){}
    ~StateB(){}
   void Handle(Context *context);
};
#endif _STATE_H_

#include 
#include 
using namespace std;
#include "State.h"

Context::Context (State *ps)
    :m_state(ps){

}
Context::~Context (){
    delete m_state;
}
void Context::Request (){
    if(m_state!=NULL){
      m_state->Handle (this);
    }
}
void Context::ChangeState (State *ps){
    if(m_state!=NULL){
      delete m_state;
      m_state = NULL;
    }
    m_state = ps;
}
void StateA::Handle (Context *context){
    cout<<"Handle By StateA!"<<endl;
    if(context!=NULL){
    context->ChangeState (new StateB());
    }    
}

void StateB::Handle (Context *context){
    cout<<"Handle By StateA!"<<endl;
    if(context!=NULL){
    context->ChangeState (new StateA());
    }    
}
int main(){
    State *pstate = new StateA();
    Context *pcontext = new Context(pstate);
    pcontext->Request ();
    pcontext->Request ();
    pcontext->Request ();
    delete pcontext;
    system("pause");
    return 0;
}

state模式很好的实现了对象的状态逻辑和动作分离，状态逻辑分布在state的派生类中实现，而动作实现则可以放在Context类中实现（state派生类中需要有一个Context指针），使得两者的变化相互独立，改变State的状态逻辑可以很容易的服用Context的动作，也可以再不影响state派生类的前提下创建Context的子类来更改或替换动作实现。

State模式问题主要是逻辑分散化，状态逻辑分布到了各个state 子类中，很难看刀到整个状态逻辑图，带来了代码的维护问题。

情绝格调(fresmaster) 2012-11-10 19:37 发表评论

Design.Patterns

情绝格调(fresmaster) — Fri, 16 Mar 2012 11:45:00 GMT

摘要: 阅读全文

情绝格调(fresmaster) 2012-03-16 19:45 发表评论

C++博客-黎明的剔透里伸出了你沁清的暧昧-随笔分类-SoftwareEngine

Some Design Pattern Ⅰ

Design.Patterns