大话设计模式中的备忘录模式的c++版本
/*
* memento.cpp
*
* Created on: Sep 29, 2017
* Author: clh01s@163.com
* 备忘录模式:在不破坏封装性的前提下,
* 捕获一个对象的内部状态,并在该对象
* 之外保存这个状态。这样就可以在之后
* 将该对象恢复到保存的状态。
*/
#include <iostream>
using namespace std;
//游戏角色状态保存类
class RoleStateMemento
{
public:
RoleStateMemento(int vit,int atk,int def):_vit(vit),_atk(atk),_def(def){}
//设置获取生命值
void SetVit(int vit){_vit = vit;}
int GetVit(){return _vit;}
//设置获取攻击力
void SetAtk(int atk){_atk = atk;}
int GetAtk(){return _atk;}
//设置获取防御力
void SetDef(int def){_def = def;}
int GetDef(){return _def;}
private:
int _vit,_atk,_def;
};
//游戏角色
class GameRole
{
public:
GameRole():_vit(100),_atk(100),_def(100){}
void StateDisplay(){cout<<"体力:"<<_vit<<endl<<"攻击力:"<<_atk<<endl<<"防御力:"<<_def<<endl;}
//战斗消耗
void Fight()
{
_vit = 10;
_atk = 10;
_def = 10;
cout<<"战斗后."<<endl;
}
//保存角色状态
RoleStateMemento* SaveState()
{
return (new RoleStateMemento(_vit,_atk,_def));
}
//恢复角色状态
void RecoveryState(RoleStateMemento* memento)
{
cout<<"载入存档...."<<endl;
_vit = memento->GetVit();
_atk = memento->GetAtk();
_def = memento->GetDef();
}
private:
int _vit,_atk,_def;
};
//角色状态管理者
class RoleStateCaretaker
{
public:
void SetMemento(RoleStateMemento* memento){_memento = memento;}
RoleStateMemento* Get_Memento(){return _memento;}
private:
RoleStateMemento* _memento;
};
int main()
{
//boos战前
GameRole clh;
clh.StateDisplay();
//保存状态
RoleStateCaretaker statadmin;
statadmin.SetMemento(clh.SaveState());
clh.Fight();
clh.StateDisplay();
//战斗后恢复状态
clh.RecoveryState(statadmin.Get_Memento());
clh.StateDisplay();
return 0;
}
输出结果:
clh@clh:~/testcode/设计模式$ ./a.out
体力:100
攻击力:100
防御力:100
战斗后.
体力:10
攻击力:10
防御力:10
载入存档....
体力:100
攻击力:100
防御力:100
以下内容均摘录自《设计模式》
可以在一下情况使用备忘录模式:
1.必须保存一个对象在某一个时刻的状态,这样以后需要时它才能恢复到先前的状态。
2.如果一个接口让其他对象直接得到这些状态,将会暴露对象的实现细节并破坏对象的封装性。
备忘录模式的优点:
1.保持封装边界 该模式把可能很复杂的originator内部信息对其他对象屏蔽起来,从而保持了封装边界
2.它简化了原发器 在其他的保持封装性的设计中,originator负责保持客户请求过的内部状态版本。这就吧所有储存管理的重任交给了originator。让客户管理它们的请求状态将会简化originator,并且使得客户工作结束时无需通知原发器。
备忘录模式的缺点:
1.使用备忘录可能代价很高 如果原发器在生成备忘录时必须拷贝并存储大量的信息,或者客户非常频繁的创建备忘录和恢复原发器状态,可能会导致非常大的开销。除非封装和恢复originator的状态开销不大,否则该模式可能并不合适。
2.定义窄接口和宽接口 在一些语言中可能难以保证只有原发器可以访问备忘录的状态。
3.维护备忘录的潜在代价 管理负责删除它所维护的备忘录。然而,管理器不知道备忘录有多少个状态。因此当存储备忘录时,一个本来很小的管理器,可能会产生大量的存储开销。
转载请注明源地址:http://blog.csdn.net/clh01s/article/details/78141418