前言
无聊的时候,也去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游戏大厅的,我也不知道,这里也完全是猜测的,请不要以此为基准。
介绍 享元模式(Flyweight),运行共享技术有效地支持大量细粒度的对象,避免大量拥有相同内容的小类的开销(如耗费内存),使大家共享一个类(元类)。 享元模式可以避免大量非常相似类的开销,在程序设计中,有时需要生产大量细粒度的类实例来表示数据,如果能发现这些实例除了几个参数以外,开销基本相同的 话,就可以大幅度较少需要实例化的类的数量。如果能把那些参数移动到类实例的外面,在方法调用的时候将他们
本文向大家介绍浅谈JAVA设计模式之享元模式,包括了浅谈JAVA设计模式之享元模式的使用技巧和注意事项,需要的朋友参考一下 享元模式(Flyweight Pattern)主要用于减少创建对象的数量,以减少内存占用和提高性能。这种类型的设计模式属于结构型模式,它提供了减少对象数量从而改善应用所需的对象结构的方式。 享元模式尝试重用现有的同类对象,如果未找到匹配的对象,则创建新对象。我们将通过创建 5
本文向大家介绍学习JavaScript设计模式之享元模式,包括了学习JavaScript设计模式之享元模式的使用技巧和注意事项,需要的朋友参考一下 一、定义 享元(flyweight)模式是一种用于性能优化的模式,核心是运用共享技术来有效支持大量细刻度的对象。 在JavaScript中,浏览器特别是移动端的浏览器分配的内存并不算多,如何节省内存就成了一个非常有意义的事情。 享元模式是一种用时间换空
享元(Flyweight) Intent 利用共享的方式来支持大量细粒度的对象,这些对象一部分内部状态是相同的。 Class Diagram Flyweight:享元对象 IntrinsicState:内部状态,享元对象共享内部状态 ExtrinsicState:外部状态,每个享元对象的外部状态不同 Implementation // java public interface Flyweight
本文向大家介绍Java设计模式之共享模式/享元模式(Flyweight模式)介绍,包括了Java设计模式之共享模式/享元模式(Flyweight模式)介绍的使用技巧和注意事项,需要的朋友参考一下 Flyweight定义:避免大量拥有相同内容的小类的开销(如耗费内存),使大家共享一个类(元类)。 为什么使用共享模式/享元模式 面向对象语言的原则就是一切都是对象,但是如果真正使用起来,有时对象数可能显
本文向大家介绍C++设计模式编程之Flyweight享元模式结构详解,包括了C++设计模式编程之Flyweight享元模式结构详解的使用技巧和注意事项,需要的朋友参考一下 由遇到的问题引出享元模式: 在面向对象系统的设计何实现中,创建对象是最为常见的操作。这里面就有一个问题:如果一个应用程序使用了太多的对象,就会造成很大的存储开销。特别是对于大量轻量级(细粒度)的对象,比如在文档编辑器的设计过程中