ReflectionToStringBuilder用法优缺点及一个问题和分享

研究ApacheCommon源码, 先从一个最简单的开始,即围绕Object类里的toString方法自动化实现的一系列类.
   
    怎么来自动化地实现toString方法, 有两种: 反射和手动设置.这两种方法在上一篇博客中都有体现 ,这里就不再赘述了.下面列举下其优缺点.

    用反射方法的优点:
        1. 代码简洁, 不需要有什么配置的.
        2, 若Model属性有变化时不必再手动更改toString方法的实现.

    缺点:
        1, 有些属性并不想让toString给输入出来, (可能是没用, 也有可能是出于密码方面考虑),但用反射时所有属性值都给输了出来. (这个已有解决,见下面,不过虽说解决了,但还是不如另一种方式灵活.)
        2, 安全方面的考虑. 一般来说,一个java类是的属性都是private的,这样用反射来构建toString方法时,就得绕过private的限制. 于是 If your system is running under a restrictive SecurityManager , you may need to alter your configuration to allow Commons Lang to bypass these security restrictions.对Java安全性问题还没有体会,现在写在这里,以作备案,提醒以后注意.

    相比于这个反射, 直接用ToStringBuilder来配置就灵活多了.

    下面说下,弥补用反射方法不够灵活的一个扩展. 由于这个是我第一次见,就放在这里,作为备案. 假设一个类里有名为password这样的属性,一般情况下,是不想让toString输入的, 但用反射默认情况下是会输出的. 这怎么办呢? 看ReflectionToStringBuilder源码里文档时,发现这么一个扩展: 通过子类,覆盖其accept方法来加以筛选.具体如下所示:

public String toString() {
      return (new ReflectionToStringBuilder(this) {
// 注意这里为了表达上的简洁用了匿名内部类.
      protected boolean accept(Field f) {
        return super.accept(f) && !f.getName().equals("password");
          }
      }).toString();
}
这样在toString时, 就会跳过名为password的属性.

    上面记录了两种方法的优缺点和反射时的扩展, 其实研究完这个ToStringBuilder后,有三个收获：

    说是收获,其实是一个问题,不过问题往往是新收获的开始. 问题是这样的:  一个private的静态内部类,它有一个同样是private的方法,名为readResolve(详见ToStringStyle的内部类 DefaultToStringStyle),那这个方法有什么用? 不用反射这个方法是不可能被调用的. 看对这个方法的描述,说是"Ensure Singleton after serialization".看不出来是什么意思? 怎么以前一直没见过呢?这个问题,先放在这里.

    两个小收获写完了,接下来将介绍研究ToStringBuilder带给我的最大收获: abstract与设计模式.

在ToStringBuilder学习（一）中提到一个问题,即 readResolve方法是干啥的? 当时也没多想, 只是列在那里, 今天忙里偷闲地把搜点材料整理下这个问题.
原来这个方法跟对象的序列化相关(这样倒是解释了为什么 readResolve方法是private修饰的). ??? 怎么跟对象的序列化相关了?

下面我们先简要地回顾下对象的序列化. 一般来说, 一个类实现了 Serializable接口, 我们就可以把它往内存地写再从内存里读出而"组装"成一个跟原来一模一样的对象. 不过当序列化遇到单例时,这里边就有了个问题: 从内存读出而组装的对象破坏了单例的规则. 单例是要求一个JVM中只有一个类对象的, 而现在通过反序列化,一个新的对象克隆了出来.
如下例所示:
public final class MySingleton implements Serializable {
     private MySingleton() { }
     private static final MySingleton INSTANCE = new MySingleton();
     public static MySingleton getInstance() { return INSTANCE; }
}

当把 MySingleton对象(通过getInstance方法获得的那个单例对象)序列化后再从内存中读出时, 就有一个全新但跟原来一样的MySingleton对象存在了. 那怎么来维护单例模式呢?这就要用到readResolve方法了. 如下所示:
public final class MySingleton implements Serializable{
    private MySingleton() { }
    private static final MySingleton INSTANCE = new MySingleton();
    public static MySingleton getInstance() { return INSTANCE; }
    private Object readResolve() throws ObjectStreamException {
       // instead of the object we're on,
       // return the class variable INSTANCE
      return INSTANCE;
   }
}
这样当JVM从内存中反序列化地"组装"一个新对象时,就会自动调用这个 readResolve方法来返回我们指定好的对象了, 单例规则也就得到了保证.