1700471381
state3=繁荣
1700471382
1700471383
通过这种方式的改造，不管有多少状态都没有问题，直接把原有的对象所有属性都备份了一遍，想恢复当时的点数据？那太容易了！
1700471384
1700471385
注意 如果要设计一个在运行期决定备份状态的框架，则建议采用AOP框架来实现，避免采用动态代理无谓地增加程序逻辑复杂性。
1700471386
1700471387
1700471388
1700471389
1700471390
设计模式之禅 24.4.3 多备份的备忘录
1700471391
1700471392
不知道你有没有做过系统级别的维护？比如Backup Administrator（备份管理员），每天负责查看系统的备份情况，所有的备份都是由自动化脚本产生的。有一天，突然有一个重要的系统说我数据库有点问题，请把上一个月末的数据拉出来恢复，那怎么办？对备份管理员来说，这很好办，直接根据时间戳找到这个备份，还原回去就成了，但是对于我们刚刚学习的备忘录模式却行不通，为什么呢？它对于一个确定的发起人，永远只有一份备份，在这种情况下，单一的备份就不能满足要求了，我们需要设计一套多备份的架构。
1700471393
1700471394
我们先来说一个名词，检查点（Check Point），也就是你在备份的时候做的戳记，系统级的备份一般是时间戳，那我们程序的检查点该怎么设计呢？一般是一个有意义的字符串。
1700471395
1700471396
我们只要把通用代码中的Caretaker管理员稍做修改就可以了，如代码清单24-20所示。
1700471397
1700471398
代码清单24-20 备忘录管理员
1700471399
1700471400
public class Caretaker{
1700471401
1700471402
//容纳备忘录的容器
1700471403
1700471404
private HashMap＜String,Memento＞memMap=new HashMap＜String,Memento＞（）；
1700471405
1700471406
public Memento getMemento（String idx）{
1700471407
1700471408
return memMap.get（idx）；
1700471409
1700471410
}
1700471411
1700471412
public void setMemento（String idx,Memento memento）{
1700471413
1700471414
this.memMap.put（idx,memento）；
1700471415
1700471416
}
1700471417
1700471418
}
1700471419
1700471420
把容纳备忘录的容器修改为Map类型就可以了，场景类也稍做改动，如代码清单24-21所示。
1700471421
1700471422
代码清单24-21 场景类
1700471423
1700471424
public class Client{
1700471425
1700471426
public static void main（String[]args）{
1700471427
1700471428
//定义出发起人
1700471429
1700471430
Originator originator=new Originator（）；
[
上一页 ]
[ :1.700471381e+09 ]
[
下一页 ]