24.4 备忘录模式的扩展

发表于 分类于 ， ， Waline： 本文字数： 10k 阅读时长 ≈ 9 分钟

24.4 备忘录模式的扩展

24.4.1 clone方式的备忘录

大家还记得在第13章中讲的原型模式吗？我们可以通过复制的方式产生一个对象的内部状态，这是一个很好的办法，发起人角色只要实现Cloneable就成，比较简单，我们来看类图，如图24-5所示。

image-20210930000232486

图24-5 Clone方式的备忘录

从类图上看，发起人角色融合了发起人角色和备忘录角色，具有双重功效，如代码清单24-12所示。

代码清单24-12 融合备忘录的发起人角色

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
public class Originator implements Cloneable{
    //内部状态
    private String state = "";
    public String getState() {
        return state;
    }
    public void setState(String state) {
        this.state = state;
    }
    //创建一个备忘录
    public Originator createMemento(){
        return this.clone();
        
    }
    //恢复一个备忘录
    public void restoreMemento(Originator _originator){
        this.setState(_originator.getState());
    }
    //克隆当前对象
    @Override
    protected Originator clone(){
        try {
            return (Originator)super.clone();
        }
        catch (CloneNotSupportedException e) {
            e.printStackTrace();
        }
        return null;
    }
}

增加了clone方法，产生了一个备份对象，需要使用的时候再还原，我们再来看管理员角色，如代码清单24-13所示。

代码清单24-13 备忘录管理员角色

1
2
3
4
5
6
7
8
9
10
public class Caretaker {
    //发起人对象
    private Originator originator;
    public Originator getOriginator() {
        return originator;
    }
    public void setOriginator(Originator originator) {
        this.originator = originator;
    }
}

没什么太大变化，只是备忘录角色转换成了发起人角色，还是一个简单的JavaBean。我们来想想这种模式是不是还可以简化？要管理员角色干什么？就是为了管理备忘录角色，现在连备忘录角色都被合并了，还留着它干吗？我们想办法把它也精简掉，如代码清单24-14 所示。

代码清单24-14 发起人自主备份和恢复

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
public class Originator implements Cloneable{
    private Originator backup;
    //内部状态
    private String state = "";
    public String getState() {
        return state;
    }
    
    public void setState(String state) {
        this.state = state;
    }
    //创建一个备忘录
    public void createMemento(){
        this.backup = this.clone();
    }
    //恢复一个备忘录
    public void restoreMemento(){
        //在进行恢复前应该进行断言，防止空指针
        this.setState(this.backup.getState());
    }
    //克隆当前对象
    @Override
    protected Originator clone(){
        try {
            return (Originator)super.clone();
        }
        catch (CloneNotSupportedException e) {
            e.printStackTrace();
        }
        return null;
    }
}

可能你要发问了，这和备忘录模式的定义不相符，它定义是“在该对象之外保存这个状态”，而你却把这个状态保存在了发起人内部。是的，设计模式定义的诞生比Java的出世略早，它没有想到Java程序是这么有活力，有远见，而且在面向对象的设计中，即使把一个类封装在另一个类中也是可以做到的，何况一个小小的对象复制，这是它的设计模式完全没有预见到的，我们把它弥补回来。

再来看看Client是如何调用的，如代码清单24-15所示。

代码清单24-15 场景类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public class Client {
    public static void main(String[] args) {
        //定义发起人
        Originator originator = new Originator();
        //建立初始状态
        originator.setState("初始状态...");
        System.out.println("初始状态是："+originator.getState());
        //建立备份
        originator.createMemento();
        //修改状态
        originator.setState("修改后的状态...");
        System.out.println("修改后状态是："+originator.getState());
        //恢复原有状态
        originator.restoreMemento();
        System.out.println("恢复后状态是："+originator.getState());
        
    }
}

运行结果如下所示：

1
2
3
初始状态是：初始状态... 
修改后状态是：修改后的状态... 
恢复后状态是：初始状态...

运行结果是我们所希望的，程序精简了很多，而且高层模块的依赖也减少了，这正是我们期望的效果。现在我们来考虑一下原型模式深拷贝和浅拷贝的问题，在复杂的场景下它会让你的程序逻辑异常混乱，出现错误也很难跟踪。因此Clone方式的备忘录模式适用于较简单的场景。

注意 使用Clone方式的备忘录模式，可以使用在比较简单的场景或者比较单一的场景中，尽量不要与其他的对象产生严重的耦合关系。

24.4.2 多状态的备忘录模式

读者应该看到我们以上讲解都是单状态的情况，在实际的开发中一个对象不可能只有一个状态，一个JavaBean有多个属性非常常见，这都是它的状态，如果照搬我们以上讲解的备忘录模式，是不是就要写一堆的状态备份、还原语句？这不是一个好办法，这种类似的非智力劳动越多，犯错误的几率越大，那我们有什么办法来处理多个状态的备份问题呢？

下面我们来讲解一个对象全状态备份方案，它有多种处理方式，比如使用Clone的方式就可以解决，使用数据技术也可以解决（DTO回写到临时表中）等，我们要讲的方案就对备忘录模式继续扩展一下，实现一个JavaBean对象的所有状态的备份和还原，如图24-6所示。

image-20210930000744163

图24-6 多状态的备忘录模式

还是比较简单的类图，增加了一个BeanUtils类，其中backupProp是把发起人的所有属性值转换到HashMap中，方便备忘录角色存储；restoreProp方法则是把HashMap中的值返回到发起人角色中。可能各位要说了，为什么要使用HashMap，直接使用Originator对象的拷贝不是一个很好的方法吗？可以这样做，你就破坏了发起人的通用性，你在做恢复动作的时候需要对该对象进行多次赋值操作，也容易产生错误。我们先来看发起人角色，如代码清单24- 16所示。

代码清单24-16 发起人角色

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
public class Originator {
    //内部状态
    private String state1 = "";
    private String state2 = "";
    private String state3 = "";
    public String getState1() {
        return state1;
    }
    public void setState1(String state1) {
        this.state1 = state1;
    }
    public String getState2() {
        return state2;
    }
    public void setState2(String state2) {
        this.state2 = state2;
    }
    public String getState3() {
        return state3;
    }
    public void setState3(String state3) {
        this.state3 = state3;
    }
    //创建一个备忘录
    public Memento createMemento(){
        return new Memento(BeanUtils.backupProp(this));
    }
    //恢复一个备忘录
    public void restoreMemento(Memento _memento){
        BeanUtils.restoreProp(this, _memento.getStateMap());
    }
    //增加一个toString方法
    @Override
    public String toString(){
        return "state1=" +state1+"\nstat2="+state2+"\nstate3="+state3;
    }
}

覆写toString方法是为了方便打印，可以让展示的结果更清晰。我们再来看BeanUtils工具类，如代码清单24-17所示。

代码清单24-17 BeanUtils工具类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
public class BeanUtils {
    //把bean的所有属性及数值放入到Hashmap中
    public static HashMap<String,Object> backupProp(Object bean){
        HashMap<String,Object> result = new HashMap<String,Object>();
        try {
            //获得Bean描述
            BeanInfo beanInfo=Introspector.getBeanInfo(bean.getClass());
            //获得属性描述
            PropertyDescriptor[] descriptors=beanInfo.getPropertyDescriptors();
            //遍历所有属性
            for(PropertyDescriptor des:descriptors){
                //属性名称
                String fieldName = des.getName();
                //读取属性的方法
                Method getter = des.getReadMethod();
                //读取属性值
                Object fieldValue=getter.invoke(bean,new Object[]{});
                if(!fieldName.equalsIgnoreCase("class")){
                    result.put(fieldName, fieldValue);
                }
            }
        }
        catch (Exception e) {
            //异常处理
        }
        return result;
    }
    //把HashMap的值返回到bean中
    public static void restoreProp(Object bean,HashMap<String,Object> propMap){
        try {
            //获得Bean描述
            BeanInfo beanInfo = Introspector.getBeanInfo(bean.getClass());
            //获得属性描述
            PropertyDescriptor[] descriptors = beanInfo.getPropertyDescriptors();
            //遍历所有属性
            for(PropertyDescriptor des:descriptors){
                //属性名称
                String fieldName = des.getName();
                //如果有这个属性
                if(propMap.containsKey(fieldName)){
                    //写属性的方法
                    Method setter = des.getWriteMethod();
                    setter.invoke(bean, new Object[]{propMap.get(fieldName)});
                }
            }
        }
        catch (Exception e) {
            //异常处理
            System.out.println("shit");
            e.printStackTrace();
        }
    }
}

该类大家在项目中会经常用到，可以作为参考使用。类似的功能有很多工具已经提供， 比如Spring、Apache工具集commons等，大家也可以直接使用。我们再来看备忘录角色，如代码清单24-18所示。

代码清单24-18 备忘录角色

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class Memento {
    //接受HashMap作为状态
    private HashMap<String,Object> stateMap;
    //接受一个对象，建立一个备份
    public Memento(HashMap<String,Object> map){
        this.stateMap = map;
    }
    public HashMap<String,Object> getStateMap() {
        return stateMap;
    }
    public void setStateMap(HashMap<String,Object> stateMap) {
        this.stateMap = stateMap;
    }
}

我们再编写一个场景类，看看我们的成果是否正确，如代码清单24-19所示。

代码清单24-19 场景类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public class Client {
    public static void main(String[] args) {
        //定义出发起人
        Originator ori = new Originator();
        //定义出备忘录管理员
        Caretaker caretaker = new Caretaker();
        //初始化
        ori.setState1("中国");
        ori.setState2("强盛");
        ori.setState3("繁荣");
        System.out.println("===初始化状态===\n"+ori);
        //创建一个备忘录
        caretaker.setMemento(ori.createMemento());
        //修改状态值
        ori.setState1("软件");
        ori.setState2("架构");
        ori.setState3("优秀");
        System.out.println("\n===修改后状态===\n"+ori);
        //恢复一个备忘录
        ori.restoreMemento(caretaker.getMemento());
        System.out.println("\n===恢复后状态===\n"+ori);
    }
}

运行结果如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
===初始化状态=== 
state1=中国 
stat2=强盛 
state3=繁荣 
===修改后状态=== 
state1=软件 
stat2=架构 
state3=优秀 
===恢复后状态=== 
state1=中国 
stat2=强盛 
state3=繁荣

通过这种方式的改造，不管有多少状态都没有问题，直接把原有的对象所有属性都备份了一遍，想恢复当时的点数据？那太容易了！

注意 如果要设计一个在运行期决定备份状态的框架，则建议采用AOP框架来实现，避 免采用动态代理无谓地增加程序逻辑复杂性。

24.4.3 多备份的备忘录

不知道你有没有做过系统级别的维护？比如Backup Administrator（备份管理员），每天负责查看系统的备份情况，所有的备份都是由自动化脚本产生的。有一天，突然有一个重要的系统说我数据库有点问题，请把上一个月末的数据拉出来恢复，那怎么办？对备份管理员来说，这很好办，直接根据时间戳找到这个备份，还原回去就成了，但是对于我们刚刚学习的备忘录模式却行不通，为什么呢？它对于一个确定的发起人，永远只有一份备份，在这种情况下，单一的备份就不能满足要求了，我们需要设计一套多备份的架构。

我们先来说一个名词，检查点（Check Point），也就是你在备份的时候做的戳记，系统级的备份一般是时间戳，那我们程序的检查点该怎么设计呢？一般是一个有意义的字符串。

我们只要把通用代码中的Caretaker管理员稍做修改就可以了，如代码清单24-20所示。

代码清单24-20 备忘录管理员

1
2
3
4
5
6
7
8
9
10
public class Caretaker {
    //容纳备忘录的容器
    private HashMap<String,Memento> memMap = new HashMap<String,Memento>();
    public Memento getMemento(String idx) {
        return memMap.get(idx);
    }
    public void setMemento(String idx,Memento memento) {
        this.memMap.put(idx, memento);
    }
}

把容纳备忘录的容器修改为Map类型就可以了，场景类也稍做改动，如代码清单24-21所示。

代码清单24-21 场景类

1
2
3
4
5
6
7
8
9
10
11
12
13
public class Client {
    public static void main(String[] args) {
        //定义出发起人
        Originator originator = new Originator();
        //定义出备忘录管理员
        Caretaker caretaker = new Caretaker();
        //创建两个备忘录
        caretaker.setMemento("001",originator.createMemento());
        caretaker.setMemento("002",originator.createMemento());
        //恢复一个指定标记的备忘录
        originator.restoreMemento(caretaker.getMemento("001"));
    }
}

注意 内存溢出问题，该备份一旦产生就装入内存，没有任何销毁的意向，这是非常危险的。因此，在系统设计时，要严格限定备忘录的创建，建议增加Map的上限，否则系统很容易产生内存溢出情况。

24.4.4 封装得更好一点

在系统管理上，一个备份的数据是完全、绝对不能修改的，它保证数据的洁净，避免数据污染而使备份失去意义。在我们的设计领域中，也存在着同样的问题，备份是不能被篡改的，也就是说需要缩小备份出的备忘录的阅读权限，保证只能是发起人可读就成了，那怎么才能做到这一点呢？使用内置类，如图24-7所示。

image-20210930094946625

图24-7 使用内置类的备忘录模式

这也是比较简单的，建立一个空接口IMemento——什么方法属性都没有的接口，然后在发起人Originator类中建立一个内置类（也叫做类中类）Memento实现IMemento接口，同时也实现自己的业务逻辑，如代码清单24-22所示。

代码清单24-22 发起人角色

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
public class Originator {
    //内部状态
    private String state = "";
    public String getState() {
        return state;
    }
    public void setState(String state) {
        this.state = state;
    }
    //创建一个备忘录
    public IMemento createMemento(){
        return new Memento(this.state);
    }
    //恢复一个备忘录
    public void restoreMemento(IMemento _memento){
        this.setState(((Memento)_memento).getState());
    }
    //内置类
    private class Memento implements IMemento{
        //发起人的内部状态
        private String state = "";
        //构造函数传递参数
        private Memento(String _state){
            this.state = _state;
        }
        private String getState() {
            return state;
        }
        private void setState(String state) {
            this.state = state;
        }
    }
}

内置类Memento全部是private的访问权限，也就是说除了发起人外，别人休想访问到， 那如果要产生关联关系又应如何处理呢？通过接口！别忘记了我们还有一个空接口是公共的访问权限，如代码清单24-23所示。

代码清单24-23 备忘录的空接口

1
2
public interface IMemento {
}

我们再来看管理者，如代码清单24-24所示。

代码清单24-24 备忘录管理者

1
2
3
4
5
6
7
8
9
10
public class Caretaker {
    //备忘录对象
    private IMemento memento;
    public IMemento getMemento() {
        return memento;
    }
    public void setMemento(IMemento memento) {
        this.memento = memento;
    }
}

全部通过接口访问，这当然没有问题，如果你想访问它的属性那是肯定不行的。但是安全是相对的，没有绝对的安全，可以使用refelect反射修改Memento的数据。

在这里我们使用了一个新的设计方法：双接口设计，我们的一个类可以实现多个接口， 在系统设计时，如果考虑对象的安全问题，则可以提供两个接口，一个是业务的正常接口， 实现必要的业务逻辑，叫做宽接口；另外一个接口是一个空接口，什么方法都没有，其目的是提供给子系统外的模块访问，比如容器对象，这个叫做窄接口，由于窄接口中没有提供任何操纵数据的方法，因此相对来说比较安全。