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
1700471084
下面我们来讲解一个对象全状态备份方案，它有多种处理方式，比如使用Clone的方式就可以解决，使用数据技术也可以解决（DTO回写到临时表中）等，我们要讲的方案就对备忘录模式继续扩展一下，实现一个JavaBean对象的所有状态的备份和还原，如图24-6所示。
1700471085
1700471086
1700471087
1700471088
1700471089
图24-6 多状态的备忘录模式
1700471090
1700471091
还是比较简单的类图，增加了一个BeanUtils类，其中backupProp是把发起人的所有属性值转换到HashMap中，方便备忘录角色存储；restoreProp方法则是把HashMap中的值返回到发起人角色中。可能各位要说了，为什么要使用HashMap，直接使用Originator对象的拷贝不是一个很好的方法吗？可以这样做，你就破坏了发起人的通用性，你在做恢复动作的时候需要对该对象进行多次赋值操作，也容易产生错误。我们先来看发起人角色，如代码清单24-16所示。
1700471092
1700471093
代码清单24-16 发起人角色
1700471094
1700471095
public class Originator{
1700471096
1700471097
//内部状态
1700471098
1700471099
private String state1=””；
1700471100
1700471101
private String state2=””；
1700471102
1700471103
private String state3=””；
1700471104
1700471105
public String getState1（）{
1700471106
1700471107
return state1；
1700471108
1700471109
}
1700471110
1700471111
public void setState1（String state1）{
1700471112
1700471113
this.state1=state1；
1700471114