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