1700471034
1700471035
//定义发起人
1700471036
1700471037
Originator originator=new Originator（）；
1700471038
1700471039
//建立初始状态
1700471040
1700471041
originator.setState（“初始状态……”）；
1700471042
1700471043
System.out.println（“初始状态是：”+originator.getState（））；
1700471044
1700471045
//建立备份
1700471046
1700471047
originator.createMemento（）；
1700471048
1700471049
//修改状态
1700471050
1700471051
originator.setState（“修改后的状态……”）；
1700471052
1700471053
System.out.println（“修改后状态是：”+originator.getState（））；
1700471054
1700471055
//恢复原有状态
1700471056
1700471057
originator.restoreMemento（）；
1700471058
1700471059
System.out.println（“恢复后状态是：”+originator.getState（））；
1700471060
1700471061
}
1700471062
1700471063
}
1700471064
1700471065
运行结果如下所示：
1700471066
1700471067
初始状态是：初始状态……
1700471068
1700471069
修改后状态是：修改后的状态……
1700471070
1700471071
恢复后状态是：初始状态……
1700471072
1700471073
运行结果是我们所希望的，程序精简了很多，而且高层模块的依赖也减少了，这正是我们期望的效果。现在我们来考虑一下原型模式深拷贝和浅拷贝的问题，在复杂的场景下它会让你的程序逻辑异常混乱，出现错误也很难跟踪。因此Clone方式的备忘录模式适用于较简单的场景。
1700471074
1700471075
注意 使用Clone方式的备忘录模式，可以使用在比较简单的场景或者比较单一的场景中，尽量不要与其他的对象产生严重的耦合关系。
1700471076
1700471077
1700471078
1700471079
1700471080
设计模式之禅 24.4.2 多状态的备忘录模式
1700471081
1700471082
读者应该看到我们以上讲解都是单状态的情况，在实际的开发中一个对象不可能只有一个状态，一个JavaBean有多个属性非常常见，这都是它的状态，如果照搬我们以上讲解的备忘录模式，是不是就要写一堆的状态备份、还原语句？这不是一个好办法，这种类似的非智力劳动越多，犯错误的几率越大，那我们有什么办法来处理多个状态的备份问题呢？
1700471083
[
上一页 ]
[ :1.700471034e+09 ]
[
下一页 ]