1700470427
1700470428
boy.changeState（）；
1700470429
1700470430
System.out.println（”\n=====男孩追女孩子后的状态======”）；
1700470431
1700470432
System.out.println（boy.getState（））；
1700470433
1700470434
//追女孩失败，恢复原状
1700470435
1700470436
boy.setState（backup.getState（））；
1700470437
1700470438
System.out.println（”\n=====男孩恢复后的状态======”）；
1700470439
1700470440
System.out.println（boy.getState（））；
1700470441
1700470442
}
1700470443
1700470444
}
1700470445
1700470446
程序运行结果如下所示：
1700470447
1700470448
=====男孩现在的状态======
1700470449
1700470450
心情很棒！
1700470451
1700470452
=====男孩追女孩子后的状态======
1700470453
1700470454
心情可能很不好
1700470455
1700470456
=====男孩恢复后的状态======
1700470457
1700470458
心情很棒！
1700470459
1700470460
程序运行正确，输出结果也是我们期望的，但是结果正确并不表示程序是最优的，我们来看看场景类Client，它代表的是高层模块，或者说是非“近亲”模块的调用者，注意看backup变量的使用，它对于高层模块完全是多余的，为什么一个状态的保存和恢复要让高层模块来负责呢？这应该是Boy类的职责，而不应该让高层模块来完成，也就是破坏了Boy类的封装，或者说Boy类没有封装好，它应该是把backup的定义容纳进来，而不应该让高层模块来定义。
1700470461
1700470462
问题我们已经知道了，就是Boy类封装不够，那我们应该如何修改呢？如果在Boy类中再增加一个方法或者其他的内部类来保存这个状态，则对单一职责原则是一种破坏，想想看单一职责原则是怎么说的？一个类的职责应该是单一的，Boy类本身的职责是追求女孩子，而保留和恢复原始状态则应该由另外一个类来承担，那我们把这个类取名就叫做备忘录，这和大家经常在桌面上贴的那个便签是一个概念，分析到这里我们的思路已经非常清楚了，我们来修改一下类图，如图24-2所示。
1700470463
1700470464
1700470465
1700470466
1700470467
图24-2 完善后的男孩状态类图
1700470468
1700470469
改动很小，增加了一个新的类Memento，负责状态的保存和备份；同时，在Boy类中增加了创建一份备忘录createMemento和恢复一个备忘录resotreMemento，我们先来看Boy类的变化，如代码清单24-3所示。
1700470470
1700470471
代码清单24-3 改进后的男孩状态类
1700470472
1700470473
public class Boy{
1700470474
1700470475
//男孩的状态
1700470476