C++设计模式之享元模式

前言

无聊的时候,也去QQ游戏大厅玩五子棋或者象棋;作为程序员,看到一个产品,总要去想想它是怎么设计的,怎么完成的,我想这个是所有程序员都会做的事情吧(强迫症???)。有的时候,想完了,还要做一个DEMO出来,才能体现自己的NB,然后还有点小成就感。

在玩五子棋或象棋的时候,我就想过,腾讯那帮伙计是怎么做的呢?五子棋的棋子有黑白两色,难道每次放一个棋子就new一个对象么?象棋有车、马、相、士、帅、炮和兵,是不是每盘棋都要把所有的棋子都new出来呢?如果真的是每一个棋子都new一个,那么再加上那么多人玩;那要new多少对象啊,如果是这样做的话,我想有多少服务器都是搞不定的,可能QQ游戏大厅会比12306还糟糕。那腾讯那帮伙计是如何实现的呢?那就要说到今天总结的享元模式了。

什么是享元模式?

在GOF的《设计模式:可复用面向对象软件的基础》一书中对享元模式是这样说的:运用共享技术有效地支持大量细粒度的对象。

就如上面说的棋子,如果每个棋子都new一个对象,就会存在大量细粒度的棋子对象,这对服务器的内存空间是一种考验,也是一种浪费。我们都知道,比如我在2013号房间和别人下五子棋,2014号房间也有人在下五子棋,并不会因为我在2013号房间,而别人在2014号房间,而导致我们的棋子是不一样的。这就是说,2013号房间和2014号房间的棋子都是一样的,所有的五子棋房间的棋子都是一样的。唯一的不同是每个棋子在不同的房间的不同棋盘的不同位置上。所以,对于棋子来说,我们不用放一个棋子就new一个棋子对象,只需要在需要的时候,去请求获得对应的棋子对象,如果没有,就new一个棋子对象;如果有了,就直接返回棋子对象。这里以五子棋为例子,进行分析,当玩家在棋盘上放入第一个白色棋子时,此时由于没有白色棋子,所以就new一个白色棋子;当另一个玩家放入第一个黑色棋子时,此时由于没有黑色棋子,所以就需要new一个黑色棋子;当玩家再次放入一个白色棋子时,就去查询是否有已经存在的白色棋子对象,由于第一次已经new了一个白色棋子对象,所以,现在不会再次new一个白色棋子对象,而是返回以前new的白色棋子对象;对于黑色棋子,亦是同理;获得了棋子对象,我们只需要设置棋子的不同棋盘位置即可。

UML类图

Flyweight:描述一个接口,通过这个接口flyweight可以接受并作用于外部状态;

ConcreteFlyweight:实现Flyweight接口,并为定义了一些内部状态,ConcreteFlyweight对象必须是可共享的;同时,它所存储的状态必须是内部的;即,它必须独立于ConcreteFlyweight对象的场景;

UnsharedConcreteFlyweight:并非所有的Flyweight子类都需要被共享。Flyweight接口使共享成为可能,但它并不强制共享。

FlyweightFactory:创建并管理flyweight对象。它需要确保合理地共享flyweight;当用户请求一个flyweight时,FlyweightFactory对象提供一个已创建的实例,如果请求的实例不存在的情况下,就新创建一个实例;

Client:维持一个对flyweight的引用;同时,它需要计算或存储flyweight的外部状态。

实现要点

根据我们的经验,当要将一个对象进行共享时,就需要考虑到对象的状态问题了;不同的客户端获得共享的对象之后,可能会修改共享对象的某些状态;大家都修改了共享对象的状态,那么就会出现对象状态的紊乱。对于享元模式,在实现时一定要考虑到共享对象的状态问题。那么享元模式是如何实现的呢?

在享元模式中,有两个非常重要的概念:内部状态和外部状态。

内部状态存储于flyweight中,它包含了独立于flyweight场景的信息,这些信息使得flyweight可以被共享。而外部状态取决于flyweight场景,并根据场景而变化,因此不可共享。用户对象负责在必要的时候将外部状态传递给flyweight。

flyweight执行时所需的状态必定是内部的或外部的。内部状态存储于ConcreteFlyweight对象之中;而外部对象则由Client对象存储或计算。当用户调用flyweight对象的操作时,将该状态传递给它。同时,用户不应该直接对ConcreteFlyweight类进行实例化,而只能从FlyweightFactory对象得到ConcreteFlyweight对象,这可以保证对它们适当地进行共享;由于共享一个实例,所以在创建这个实例时,就可以考虑使用单例模式来进行实现。

享元模式的工厂类维护了一个实例列表,这个列表中保存了所有的共享实例;当用户从享元模式的工厂类请求共享对象时,首先查询这个实例表,如果不存在对应实例,则创建一个;如果存在,则直接返回对应的实例。

代码实现:

代码如下:

#include <iostream>
#include <map>
#include <vector>
using namespace std;
 
typedef struct pointTag
{
    int x;
    int y;
 
    pointTag(){}
    pointTag(int a, int b)
    {
        x = a;
        y = b;
    }
 
     bool operator <(const pointTag& other) const
     {
         if (x < other.x)
         {
             return true;
         }
         else if (x == other.x)
         {
             return y < other.y;
         }
 
         return false;
     }
}POINT;
 
typedef enum PieceColorTag
{
    BLACK,
    WHITE
}PIECECOLOR;
 
class CPiece
{
public:
    CPiece(PIECECOLOR color) : m_color(color){}
    PIECECOLOR GetColor() { return m_color; }
 
    // Set the external state
    void SetPoint(POINT point) { m_point = point; }
    POINT GetPoint() { return m_point; }
 
protected:
    // Internal state
    PIECECOLOR m_color;
 
    // external state
    POINT m_point;
};
 
class CGomoku : public CPiece
{
public:
    CGomoku(PIECECOLOR color) : CPiece(color){}
};
 
class CPieceFactory
{
public:
    CPiece *GetPiece(PIECECOLOR color)
    {
        CPiece *pPiece = NULL;
        if (m_vecPiece.empty())
        {
            pPiece = new CGomoku(color);
            m_vecPiece.push_back(pPiece);
        }
        else
        {
            bool bFound = false; // 非常感谢fireace指出的问题
            for (vector<CPiece *>::iterator it = m_vecPiece.begin(); it != m_vecPiece.end(); ++it)
            {
                if ((*it)->GetColor() == color)
                {
                    bFound = true;
                    pPiece = *it;
                    break;
                }
                bFound = false;
            }
            if (!bFound)
            {
                pPiece = new CGomoku(color);
                m_vecPiece.push_back(pPiece);
            }
        }
        return pPiece;
    }
 
    ~CPieceFactory()
    {
        for (vector<CPiece *>::iterator it = m_vecPiece.begin(); it != m_vecPiece.end(); ++it)
        {
            if (*it != NULL)
            {
                delete *it;
                *it = NULL;
            }
        }
    }
 
private:
    vector<CPiece *> m_vecPiece;
};
 
class CChessboard
{
public:
    void Draw(CPiece *piece)
    {
        if (piece->GetColor())
        {
            cout<<"Draw a White"<<" at ("<<piece->GetPoint().x<<","<<piece->GetPoint().y<<")"<<endl;
        }
        else
        {
            cout<<"Draw a Black"<<" at ("<<piece->GetPoint().x<<","<<piece->GetPoint().y<<")"<<endl;
        }
        m_mapPieces.insert(pair<POINT, CPiece *>(piece->GetPoint(), piece));
    }
 
    void ShowAllPieces()
    {
        for (map<POINT, CPiece *>::iterator it = m_mapPieces.begin(); it != m_mapPieces.end(); ++it)
        {
            if (it->second->GetColor())
            {
                cout<<"("<<it->first.x<<","<<it->first.y<<") has a White chese."<<endl;
            }
            else
            {
                cout<<"("<<it->first.x<<","<<it->first.y<<") has a Black chese."<<endl;
            }
        }
    }
 
private:
    map<POINT, CPiece *> m_mapPieces;
};
 
int main()
{
    CPieceFactory *pPieceFactory = new CPieceFactory();
    CChessboard *pCheseboard = new CChessboard();
 
    // The player1 get a white piece from the pieces bowl
    CPiece *pPiece = pPieceFactory->GetPiece(WHITE);
    pPiece->SetPoint(POINT(2, 3));
    pCheseboard->Draw(pPiece);
 
    // The player2 get a black piece from the pieces bowl
    pPiece = pPieceFactory->GetPiece(BLACK);
    pPiece->SetPoint(POINT(4, 5));
    pCheseboard->Draw(pPiece);
 
    // The player1 get a white piece from the pieces bowl
    pPiece = pPieceFactory->GetPiece(WHITE);
    pPiece->SetPoint(POINT(2, 4));
    pCheseboard->Draw(pPiece);
 
    // The player2 get a black piece from the pieces bowl
    pPiece = pPieceFactory->GetPiece(BLACK);
    pPiece->SetPoint(POINT(3, 5));
    pCheseboard->Draw(pPiece);
 
    /*......*/
 
    //Show all cheses
    cout<<"Show all cheses"<<endl;
    pCheseboard->ShowAllPieces();
 
    if (pCheseboard != NULL)
    {
        delete pCheseboard;
        pCheseboard = NULL;
    }
    if (pPieceFactory != NULL)
    {
        delete pPieceFactory;
        pPieceFactory = NULL;
    }
}

内部状态包括棋子的颜色,外部状态包括棋子在棋盘上的位置。最终,我们省去了多个实例对象存储棋子颜色的空间,从而达到了空间的节约。

在上面的代码中,我建立了一个CCheseboard用于表示棋盘,棋盘类中保存了放置的黑色棋子和白色棋子;这就相当于在外部保存了共享对象的外部状态;对于棋盘对象,我们是不是又可以使用享元模式呢?再设计一个棋局类进行管理棋盘上的棋子布局,用来保存外部状态。对于这个,这里不进行讨论了。

优点

享元模式可以避免大量非常相似对象的开销。在程序设计时,有时需要生成大量细粒度的类实例来表示数据。如果能发现这些实例数据除了几个参数外基本都是相同的,使用享元模式就可以大幅度地减少对象的数量。

使用场合

Flyweight模式的有效性很大程度上取决于如何使用它以及在何处使用它。当以下条件满足时,我们就可以使用享元模式了。

1.一个应用程序使用了大量的对象;
2.完全由于使用大量的对象,造成很大的存储开销;
3.对象的大多数状态都可变为外部状态;
4.如果删除对象的外部状态,那么可以用相对较少的共享对象取代很多组对象。

扩展

之前总结了组合模式组合模式,现在回过头来看看,享元模式就好比在组合模式的基础上加上了一个工厂类,进行共享控制。是的,组合模式有的时候会产生很多细粒度的对象,很多时候,我们会将享元模式和组合模式进行结合使用。

总结

使用享元模式可以避免大量相似对象的开销,减小了空间消耗;而空间的消耗是由以下几个因素决定的:

1.实例对象减少的数目;
2.对象内部状态的数目;对象内部状态越多,消耗的空间也会越少;
3.外部状态是计算的还是存储的;由于外部状态可能需要存储,如果外部状态存储起来,那么空间的节省就不会太多。

共享的Flyweight越多,存储节约也就越多,节约量随着共享状态的增多而增大。当对象使用大量的内部及外部状态,并且外部状态是计算出来的而非存储的时候,节约量将达到最大。所以,可以使用两种方法来节约存储:用共享减少内部状态的消耗;用计算时间换取对外部状态的存储。

同时,在实现的时候,一定要控制好外部状态与共享对象的对应关系,比如我在代码实现部分,在CCheseboard类中使用了一个map进行彼此之间的映射,这个映射在实际开发中需要考虑的。

好了,享元模式就总结到这里了。希望大家和我分享你对设计模式的理解。我坚信:分享使我们更进步。
PS:至于腾讯那帮伙计到底是如何实现QQ游戏大厅的,我也不知道,这里也完全是猜测的,请不要以此为基准。

(0)

相关推荐

  • 举例解析设计模式中的工厂方法模式在C++编程中的运用

    工厂方法模式不同于简单工厂模式的地方在于工厂方法模式把对象的创建过程放到里子类里.这样工厂父对象和产品父对象一样,可以是抽象类或者接口,只定义相应的规范或操作,不涉及具体的创建或实现细节. 其类图如下: 实例代码为: #pragma once class IProduct { public: IProduct(void); virtual ~IProduct(void); }; #pragma once #include "iproduct.h" class IPad : public

  • 实例解析C++设计模式编程中简单工厂模式的采用

    简单工厂模式中专门定义一个类来负责创建其他类的实例,被创建的实例通常都具有共同的父类.它又称为静态工厂方法模式,属于类的创建型模式. 简单工厂模式的UML类图 简单工厂模式的程序通过封装继承来降低程序的耦合度,设计模式使得程序更加的灵活,易修该,易于复用. 简单工厂是在工厂类中做判断,从而创造相应的产品. 简单工厂模式的实质是由一个工厂类根据传入的参数,动态决定应该创建哪一个产品类(这些产品类继承自一个父类或接口)的实例.   该模式中包含的角色及其职责   1.工厂(Creator)角色  

  • 使用设计模式中的单例模式来实现C++的boost库

    线程安全的单例模式 一.懒汉模式:即第一次调用该类实例的时候才产生一个新的该类实例,并在以后仅返回此实例. 需要用锁,来保证其线程安全性:原因:多个线程可能进入判断是否已经存在实例的if语句,从而non thread safety. 使用double-check来保证thread safety.但是如果处理大量数据时,该锁才成为严重的性能瓶颈. 1.静态成员实例的懒汉模式: class Singleton { private: static Singleton* m_instance; Sing

  • 详解C++设计模式编程中策略模式的优缺点及实现

    策略模式(Strategy):它定义了一系列的算法,并将每一个算法封装起来,而且使它们还可以相互替换.策略模式让算法的变化不会影响到使用算法的客户.策略模式和 Template 模式要解决的问题是相同(类似)的,都是为了给业务逻辑(算法)具体实现和抽象接口之间的解耦.策略模式将逻辑(算法)封装到一个类(Context)里面,通过组合的方式将具体算法的实现在组合对象中实现,再通过委托的方式将抽象接口的实现委托给组合对象实现.State 模式也有类似的功能,他们之间的区别将在讨论中给出. UML图

  • 详解C++设计模式编程中建造者模式的实现

    建造者模式:将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示.这是建造者模式的标准表达,不过看着让人迷惑,什么叫构建和表示的分离?一个对象使用构造函数构造之后不就固定了,只有通过它方法来改变它的属性吗?而且还要同样的构建过程搞出不同的表示,怎么可能呢?多写几个构造函数? 其实多写几个构造函数,根据不同参数设置对象不同的属性,也可以达到这样的效果,只是这样就非常麻烦了,每次要增加一种表示就要添加一个构造函数,将来构造函数会多得连自己都不记得了,这违背了开放-封闭的原则. 要

  • C++设计模式之策略模式

    前言 刚刚加班回来:哎,公司规定平时加班只有10块钱的餐补:星期六和星期天加班,只给串休假:在国家规定的节假日按照3倍工资发放.那么对于这么多的计算加班费的方法,公司的OA系统是如何进行做的呢?这就要说到今天我这里总结的策略设计模式了. 策略模式 在GOF的<设计模式:可复用面向对象软件的基础>一书中对策略模式是这样说的:定义一系列的算法,把它们一个个封装起来,并且使它们可相互替换.该模式使得算法可独立于使用它的客户而变化. 策略模式为了适应不同的需求,只把变化点封装了,这个变化点就是实现不同

  • C++设计模式之状态模式

    前言 在实际开发中,我们经常会遇到这种情况:一个对象有多种状态,在每一个状态下,都会有不同的行为.那么在代码中我们经常是这样实现的. 复制代码 代码如下: typedef enum tagState {      state,      state1,      state2 }State;   void Action(State actionState) {      if (actionState == state)      {           // DoSomething     

  • C++设计模式编程中的观察者模式使用示例

    概述: 最近中国股市起起伏伏,当然了起伏就用商机,小明发现商机后果断想入市,买入了中国证券,他想在电脑客户端上,网页上,手机上,iPad上都可以查看到该证券的实时行情,这种情况下我们应该怎么设计我们的软件呢?我们可以这样:小明的所有客户端上都订阅中国证券这个股票,只要股票一有变化,所有的客户端都会被通知到并且被自动更新. 这就是我们的观察者模式,她定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新. 类图: 可以看出,在这个观察者模式的实现里

  • C++设计模式之模板方法模式

    前言 离开了自己工作了将近两年的公司,日子不再有了忙碌,可以闲下来,躺在家里的床上,想着以后的路怎么走,说实话,真的很迷茫,从2012年毕业到现在,时间不长,但是学到的东西真的是非常有限,一直从事于Windows平台上的开发.说到Windows平台的开发,大家都肯定知道的HOOK的,即使不知道HOOK,对于COM应该也是知道的,我的系列博文中也对COM进行过全面的总结.说白了,HOOK就是在执行某个功能时,会有一个一系列的执行过程,对于这个过程一般都是固定的,比如:第一步执行什么,第二步干什么,

  • C++设计模式之访问者模式

    前言 这是23+1(简单工厂模式)之中的最后一个了--访问者模式.访问者模式也是一个比较麻烦的设计模式.我也没有实战经验,对于访问者模式的理解完全来自GOF的<设计模式:可复用面向对象软件的基础>,而这篇文章就是根据对这本书的理解而写出来的.在读<设计模式:可复用面向对象软件的基础>的时候,让我想起自己做过的一个项目,该项目虽然没有使用访问者模式,但是,今天理解了该模式,如果使用该模式对之前做过的项目进行重构,将是一个不错的想法. 访问者模式 在GOF的<设计模式:可复用面向

随机推荐