CJC是Common Java Cookbook的缩写, 这是一本介绍ApacheCommon开源项目的电子书 . 在这里,CJC代表我对其源码研究的系列博客.为什么要研究它?若有兴趣请看另一篇博客,避害趋利 .
------------------------
这是第一篇研究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与设计模式.