ToStringBuilder学习（二）：两种方法用法优缺点及一个问题

研究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与设计模式.