“状态变化”模式
在组建构建过程中，某些对象的状态经常面临变化，如何对这些变化进行有效的管理？同时又维持高层模块的稳定？“状态变化”模式为这一个问题提供了一种解决方案。
- 典型模式
- State
- Memento
状态模式（State）
允许一个对象在其内部状态改变是改变它的行为。从而使对像看起来似乎修改其行为。
——《设计模式》GoF
- 动机
在软件构建过程中，某些对象的状态如果改变，其行为也会随之而发生变化，比如文档处于只读状态，其支持的行为和读写状态支持的行为就可能会完全不同。
假设有一个网络的应用，移动有三种状态，打开、关闭和连接。
操作针对不同的状态会执行不同的行为。（状态不同，行为不同）
同时执行一次操作完毕后，也会更改状态。
enum NetworkState
{
Network_Open,
Network_Close,
Network_Connect,
};
class NetworkProcessor{
NetworkState state;
public:
void Operation1(){
if (state == Network_Open){
//**********
state = Network_Close;
}
else if (state == Network_Close){
//..........
state = Network_Connect;
}
else if (state == Network_Connect){
//$$$$$$$$$$
state = Network_Open;
}
}
public void Operation2(){
if (state == Network_Open){
//**********
state = Network_Connect;
}
else if (state == Network_Close){
//.....
state = Network_Open;
}
else if (state == Network_Connect){
//$$$$$$$$$$
state = Network_Close;
}
}
public void Operation3(){
}
};
对于上面的代码来说，未来状态是否会发生变化？如果出现了新的变化，那么之后的所有的代码，全部都需要改变，违背了开闭原则。
那么根据Strategy模式的启发，我们把状态的向上抽象，每个自己实现出来的状态，将所有跟状态有关的操作全都变成具体的状态对像的行为。每个状态也可以次啊用单例的模式。每个状态的操作之后，可以根据他的操作完后，在操作的方法中，将自动定义下一个状态。对于调用者来说，每次的状态改变只需要将指针指向操作所改变的下一个对象即可，那么使用者完全不需要考虑下一个状态是什么，因为在制定状态的操作中已经改变好了。
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;
//...
}
};
State的UML
要点总结
- State模式将所有与一个特定状态相关的行为都放入一个State的子类对象中，在对像状态切换时， 切换相应的对象；但同时维持State的接口，这样实现了具体操作与状态转换之间的解耦。
- 为不同的状态引入不同的对象使得状态转换变得更加明确，而且可以保证不会出现状态不一致的情况，因为转换是原子性的——即要么彻底转换过来，要么不转换。
- 如果State对象没有实例变量，那么各个上下文可以共享同一个State对象，从而节省对象开销。
备忘录（Memento）
在不破坏封装性的前提下，不活一个对象的内部状态，并在该对像之外保存这个状态。这样以后就可以将该对像恢复到原想保存的状态。
——《设计模式》GoF
- 动机
在软件构建过程中，某些对象的状态在转会过程中，可能由于某种需求，要求程序能够回溯到对像之前处于某个点时的状态。如果使用一些公有借口来让其它对象得到对象的状态，便会暴露对象的实现细节。
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);
}
假设Originator是一个需要被保存的对象，他的内部可能有很多的状态，我们有一个需求：在某一个时间节点，为这个对象拍一个快照。那么我们设计了一个Memento对象，其中具有和Originator需要备份的属性。Memento具有供外界调用的接口。那么被创建的备份，应该是稳定的，外界只有读取信息的结构，没有修改信息的接口。
在Orginator还应该具有从Memento恢复的方法，来依靠之前所存储的快照进行恢复。
以上仅仅是一个示意性的伪码描述，也可以通过其他的手段来实现Memento的过程，比如对象的序列化和反序列化等等。
Memento的UML
要点总结
备忘录（Memento）存储原发器（Originator）对象的内部状态，在需要时恢复原发器的状态。
Memento模式的核心是信息隐藏，即Originator需要向外接隐藏信息，保持其封装性。但同时又需要将其状态保持到外界（Memento）
由于现代语言运行时（如C#、java等）都具有相当的对象序列化支持，因此往往采用效率较高、有较容易正确实现的序列化方案来实现Memento模式。
由于《设计模式》是在94年定义的，现在很多的技术发展已经变化，现在Memento的实现方法已经过时了，现在在使用其他的方式在做这件事，但是对于思想并没有发生变化。在备份的过程中，还需要保持封装的时候，将信息保存到外部。
网友评论