CJC(一): ToStringBuilder两种方法用法优缺点及一个问题 - rmn190 - ITeye技术网站

CJC(一): ToStringBuilder两种方法用法优缺点及一个问题 - rmn190 - ITeye技术网站

     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方法来加以筛选.具体如下所示:

Java代码  
  1. public String toString() {  
  2.       return (new ReflectionToStringBuilder(this) {// 注意这里为了表达上的简洁用了匿名内部类.  
  3.           protected boolean accept(Field f) {  
  4.               return super.accept(f) && !f.getName().equals("password");  
  5.           }  
  6.       }).toString();  
  7. }  

 



这样在toString时, 就会跳过名为password的属性.



    上面记录了两种方法的优缺点和反射时的扩展, 其实研究完这个ToStringBuilder后,有三个收获,上面只是第一个,第三个相对来说比较大,只能放在下一篇了,这里介绍下第二个收获.



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



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

你可能感兴趣的:(StringBuilder)