编写高质量代码:改善Java程序的151个建议(第1章:JAVA开发中通用的方法和准则___建议16~20)

建议16:易变业务使用脚本语言编写

  Java世界一直在遭受着异种语言的入侵,比如PHP,Ruby,Groovy、Javascript等,这些入侵者都有一个共同特征:全是同一类语言-----脚本语言,它们都是在运行期解释执行的。为什么Java这种强编译型语言会需要这些脚本语言呢?那是因为脚本语言的三大特征,如下所示:

  1. 灵活:脚本语言一般都是动态类型,可以不用声明变量类型而直接使用,可以再运行期改变类型。  
  2. 便捷:脚本语言是一种解释性语言,不需要编译成二进制代码,也不需要像Java一样生成字节码。它的执行时依靠解释器解释的,因此在运行期间变更代码很容易,而且不用停止应用;
  3. 简单:只能说部分脚本语言简单,比如Groovy,对于程序员来说,没有多大的门槛。

  脚本语言的这些特性是Java缺少的,引入脚本语言可以使Java更强大,于是Java6开始正式支持脚本语言。但是因为脚本语言比较多,Java的开发者也很难确定该支持哪种语言,于是JSCP(Java Community ProCess)很聪明的提出了JSR233规范,只要符合该规范的语言都可以在Java平台上运行(它对JavaScript是默认支持的)。

  简单看看下面这个小例子:

function formual(var1, var2){
     return var1 + var2 * factor;
 }

这就是一个简单的脚本语言函数,可能你会很疑惑:factor(因子)这个变量是从那儿来的?它是从上下文来的,类似于一个运行的环境变量。该js保存在C:/model.js中,下一步需要调用JavaScript公式,代码如下:

 1 import java.io.FileNotFoundException;
 2 import java.io.FileReader;
 3 import java.util.Scanner;
 4 
 5 import javax.script.Bindings;
 6 import javax.script.Invocable;
 7 import javax.script.ScriptContext;
 8 import javax.script.ScriptEngine;
 9 import javax.script.ScriptEngineManager;
10 import javax.script.ScriptException;
11 
12 public class Client16 {
13     public static void main(String[] args) throws FileNotFoundException,
14             ScriptException, NoSuchMethodException {
15         // 获得一个JavaScript执行引擎
16         ScriptEngine engine = new ScriptEngineManager().getEngineByName("javascript");
17         // 建立上下文变量
18         Bindings bind = engine.createBindings();
19         bind.put("factor", 1);
20         // 绑定上下文,作用于是当前引擎范围
21         engine.setBindings(bind, ScriptContext.ENGINE_SCOPE);
22         Scanner input =new Scanner(System.in);
23         
24         while(input.hasNextInt()){
25             int first = input.nextInt();
26             int second = input.nextInt();
27             System.out.println("输入参数是:"+first+","+second);
28             // 执行Js代码
29             engine.eval(new FileReader("C:/model.js"));
30             // 是否可调用方法
31             if (engine instanceof Invocable) {
32                 Invocable in = (Invocable) engine;
33                 // 执行Js中的函数
34                 Double result = (Double) in.invokeFunction("formula", first, second);
35                 System.out.println("运算结果是:" + result.intValue());
36             }
37         }
38 
39     }
40 }

上段代码使用Scanner类接受键盘输入的两个数字,然后调用JavaScript脚本的formula函数计算其结果,注意,除非输入了一个非int数字,否则当前JVM会一直运行,这也是模拟生成系统的在线变更情况。运行结果如下:

 输入参数是;1,2  运算结果是:3

此时,保持JVM的运行状态,我们修改一下formula函数,代码如下:

function formual(var1, var2){
     return var1 + var2 - factor;
 }

其中,乘号变成了减号,计算公式发生了重大改变。回到JVM中继续输入,运行结果如下:

输入参数:1,2  运行结果是:2

     修改Js代码,JVM没有重启,输入参数也没有任何改变,仅仅改变脚本函数即可产生不同的效果。这就是脚本语言对系统设计最有利的地方:可以随时发布而不用部署;这也是我们javaer最喜爱它的地方----即使进行变更,也能提供不间断的业务服务。

   Java6不仅仅提供了代码级的脚本内置,还提供了jrunscript命令工具,它可以再批处理中发挥最大效能,而且不需要通过JVM解释脚本语言,可以直接通过该工具运行脚本。想想看。这是多么大的诱惑力呀!而且这个工具是可以跨操作系统的,脚本移植就更容易了。

建议17:慎用动态编译

   动态编译一直是java的梦想,从Java6开始支持动态编译了,可以再运行期直接编译.java文件,执行.class,并且获得相关的输入输出,甚至还能监听相关的事件。不过,我们最期望的还是定一段代码,直接编译,然后运行,也就是空中编译执行(on-the-fly),看如下代码:

 1 import java.io.IOException;
 2 import java.lang.reflect.Method;
 3 import java.net.URI;
 4 import java.util.ArrayList;
 5 import java.util.Arrays;
 6 import java.util.List;
 7 
 8 import javax.tools.JavaCompiler;
 9 import javax.tools.JavaFileObject;
10 import javax.tools.SimpleJavaFileObject;
11 import javax.tools.StandardJavaFileManager;
12 import javax.tools.ToolProvider;
13 
14 public class Client17 {
15     public static void main(String[] args) throws Exception {
16         // Java源代码
17         String sourceStr = "public class Hello { public String sayHello (String name) {return \"Hello,\"+name+\"!\";}}";
18         // 类名及文件名
19         String clsName = "Hello";
20         // 方法名
21         String methodName = "sayHello";
22         // 当前编译器
23         JavaCompiler cmp = ToolProvider.getSystemJavaCompiler();
24         // Java标准文件管理器
25         StandardJavaFileManager fm = cmp.getStandardFileManager(null, null,
26                 null);
27         // Java文件对象
28         JavaFileObject jfo = new StringJavaObject(clsName, sourceStr);
29         // 编译参数,类似于javac <options>中的options
30         List<String> optionsList = new ArrayList<String>();
31         // 编译文件的存放地方,注意:此处是为Eclipse工具特设的
32         optionsList.addAll(Arrays.asList("-d", "./bin"));
33         // 要编译的单元
34         List<JavaFileObject> jfos = Arrays.asList(jfo);
35         // 设置编译环境
36         JavaCompiler.CompilationTask task = cmp.getTask(null, fm, null,
37                 optionsList, null, jfos);
38         // 编译成功
39         if (task.call()) {
40             // 生成对象
41             Object obj = Class.forName(clsName).newInstance();
42             Class<? extends Object> cls = obj.getClass();
43             // 调用sayHello方法
44             Method m = cls.getMethod(methodName, String.class);
45             String str = (String) m.invoke(obj, "Dynamic Compilation");
46             System.out.println(str);
47         }
48 
49     }
50 }
51 
52 class StringJavaObject extends SimpleJavaFileObject {
53     // 源代码
54     private String content = "";
55 
56     // 遵循Java规范的类名及文件
57     public StringJavaObject(String _javaFileName, String _content) {
58         super(_createStringJavaObjectUri(_javaFileName), Kind.SOURCE);
59         content = _content;
60     }
61 
62     // 产生一个URL资源路径
63     private static URI _createStringJavaObjectUri(String name) {
64         // 注意,此处没有设置包名
65         return URI.create("String:///" + name + Kind.SOURCE.extension);
66     }
67 
68     // 文本文件代码
69     @Override
70     public CharSequence getCharContent(boolean ignoreEncodingErrors)
71             throws IOException {
72         return content;
73     }
74 }

上面代码较多,可以作为一个动态编译的模板程序。只要是在本地静态编译能够实现的任务,比如编译参数,输入输出,错误监控等,动态编译都能实现。

  Java的动态编译对源提供了多个渠道。比如,可以是字符串,文本文件,字节码文件,还有存放在数据库中的明文代码或者字节码。汇总一句话,只要符合Java规范的就可以在运行期动态加载,其实现方式就是实现JavaFileObject接口,重写getCharContent、openInputStream、openOutputStream,或者实现JDK已经提供的两个SimpleJavaFileObject、ForwardingJavaFileObject,具体代码可以参考上个例子。

  动态编译虽然是很好的工具,让我们可以更加自如的控制编译过程,但是在我们目前所接触的项目中还是使用较少。原因很简单,静态编译已经能够帮我们处理大部分的工作,甚至是全部的工作,即使真的需要动态编译,也有很好的替代方案,比如Jruby、Groovy等无缝的脚本语言。另外,我们在使用动态编译时,需要注意以下几点:

  1. 在框架中谨慎使用:比如要在struts中使用动态编译,动态实现一个类,它若继承自ActionSupport就希望它成为一个Action。能做到,但是debug很困难;再比如在Spring中,写一个动态类,要让它注入到Spring容器中,这是需要花费老大功夫的。
  2. 不要在要求性能高的项目中使用:如果你在web界面上提供了一个功能,允许上传一个java文件然后运行,那就等于说:"我的机器没有密码,大家都可以看看",这是非常典型的注入漏洞,只要上传一个恶意Java程序就可以让你所有的安全工作毁于一旦。
  3. 记录动态编译过程:建议记录源文件,目标文件,编译过程,执行过程等日志,不仅仅是为了诊断,还是为了安全和审计,对Java项目来说,空中编译和运行时很不让人放心的,留下这些依据可以很好地优化程序。

建议18:避免instanceof非预期结果

 instanceof是一个简单的二元操作符,它是用来判断一个对象是否是一个类的实现,其操作类似于>=、==,非常简单,我们看段程序,代码如下:  

 1 import java.util.Date;
 2 
 3 public class Client18 {
 4     public static void main(String[] args) {
 5         // String对象是否是Object的实例 true
 6         boolean b1 = "String" instanceof Object;
 7         // String对象是否是String的实例 true
 8         boolean b2 = new String() instanceof String;
 9         // Object对象是否是String的实例 false
10         boolean b3 = new Object() instanceof String;
11         // 拆箱类型是否是装箱类型的实例 编译不通过
12         boolean b4 = 'A' instanceof Character;
13         // 空对象是否是String的实例 false
14         boolean b5 = null instanceof String;
15         // 转换后的空对象是否是String的实例 false
16         boolean b6 = (String) null instanceof String;
17         // Date是否是String的实例 编译不通过
18         boolean b7 = new Date() instanceof String;
19         // 在泛型类型中判断String对象是否是Date的实例 false
20         boolean b8 = new GenericClass<String>().isDateInstance("");
21 
22     }
23 }
24 
25 class GenericClass<T> {
26     // 判断是否是Date类型
27     public boolean isDateInstance(T t) {
28         return t instanceof Date;
29     }
30 
31 }

就这么一段程序,instanceof的应用场景基本都出现了,同时问题也产生了:这段程序中哪些语句编译不通过,我们一个一个的解释说:

  1. "String" instanceof Object:返回值是true,这很正常,"String"是一个字符串,字符串又继承了Object,那当然返回true了。
  2. new String() instanceof String:返回值是true,没有任何问题,一个类的对象当然是它的实例了。
  3. new Object() instanceof String:返回值为false,Object是父类,其对象当然不是String类的实例了。要注意的是,这句话其实完全可以编译通过,只要instanceof关键字的左右两个操作数有继承或实现关系,就可以编译通过。
  4. 'A' instanceof Character:这句话编译不通过,为什么呢?因为'A'是一个char类型,也就是一个基本类型,不是一个对象,instanceof只能用于对象的判断,不能用于基本类型的判断。
  5. null instanceof String:返回值为false,这是instanceof特有的规则,若做操作数为null,结果就直接返回false,不再运算右操作数是什么类。这对我们的程序非常有利,在使用instanceof操作符时,不用关心被判断的类(也就是左操作数)是否为null,这与我们经常用到的equals、toString方法不同。
  6. (String) null instanceof String:返回值为false,不要看这里有个强制类型转换就认为结果是true,不是的,null是一个万用类型,也就是说它可以没类型,即使做类型转换还是个null。
  7. new Date() instanceof String:编译不通过,因为Date类和String没有继承或实现关系,所以在编译时就直接报错了,instanceof操作符的左右操作数必须有继承或实现关系,否则编译会失败。
  8. new GenericClass<String>().isDateInstance(""):编译不通过,非也,编译通过了,返回值为false,T是个String类型,于Date之间没有继承或实现关系,为什么"t instanceof Date"会编译通过呢?那是因为Java的泛型是为编码服务的,在编译成字节码时,T已经是Object类型了传递的实参是String类型,也就是说T的表面类型是Object,实际类型是String,那么"t instanceof Date"等价于"Object instanceof Date"了,所以返回false就很正常了。

建议19:断言绝对不是鸡肋

  在防御式编程中经常会用断言(Assertion)对参数和环境做出判断,避免程序因不当的判断或输入错误而产生逻辑异常,断言在很多语言中都存在,C、C++、Python都有不同的断言表现形式.在Java中断言使用的是assert关键字,其基本用法如下:

  assert<布尔表达式>

  assert<布尔表达式> : <错误信息>

在布尔表达式为假时,跑出AssertionError错误,并附带了错误信息。assert的语法比较简单,有以下两个特性:

  (1)、assert默认是不启用的

      我们知道断言是为调试程序服务的,目的是为了能够迅速、方便地检查到程序异常,但Java在默认条件下是不启用的,要启用就要在编译、运行时加上相关的关键字,这就不多说,有需要的话可以参考一下Java规范。

  (2)、assert跑出的异常AssertionError是继承自Error的

      断言失败后,JVM会抛出一个AssertionError的错误,它继承自Error,注意,这是一个错误,不可恢复,也就是表明这是一个严重问题,开发者必须予以关注并解决之。

  assert虽然是做断言的,但不能将其等价于if...else...这样的条件判断,它在以下两种情况下不可使用:

  (1)、在对外的公开方法中

    我们知道防御式编程最核心的一点就是:所有的外部因素(输入参数、环境变量、上下文)都是"邪恶"的,都存在着企图摧毁程序的罪恶本源,为了抵制它,我们要在程序处处检验。满地设卡,不满足条件,就不执行后续程序,以保护后续程序的正确性,处处设卡没问题,但就是不能用断言做输入校验,特别是公开方法。我们开看一个例子: 

 1 public class Client19 {
 2     public static void main(String[] args) {
 3         System.out.println(StringUtils.encode(null));;
 4     }
 5 }
 6 
 7 class StringUtils{
 8     public static String encode(String str){
 9         assert    str != null : "加密的字符串为null";
10         /*加密处理*/
11         return str;
12         
13     }
14 }

  encode方法对输入参数做了不为空的假设,如果为空,则抛出AssertionError错误,但这段程序存在一个严重的问题,encode是一个public方法,这标志着它时对外公开的,任何一个类只要能传递一个String类型的参数(遵守契约)就可以调用,但是Client19类按照规定和契约调用encode方法,却获得了一个AssertionError错误信息,是谁破坏了契约协议?---是encode方法自己。

  (2)、在执行逻辑代码的情况下

    assert的支持是可选的,在开发时可以让他运行,但在生产环境中系统则不需要其运行了(以便提高性能),因此在assert的布尔表达式中不能执行逻辑代码,否则会因为环境的不同而产生不同的逻辑,例如: 

public void doSomething(List list, Object element) {
        assert list.remove(element) : "删除元素" + element + "失败";
        /*业务处理*/
    }

这段代码在assert启用的环境下没有任何问题,但是一但投入到生成环境,就不会启用断言了,而这个方法就彻底完蛋了,list的删除动作永远不会执行,所以就永远不会报错或异常了,因为根本就没有执行嘛!

  以上两种情况下不能使用断言assert,那在什么情况下能够使用assert呢?一句话:按照正常的执行逻辑不可能到达的代码区域可以防止assert。具体分为三种情况:

  1. 在私有方法中放置assert作为输入参数的校验:在私有方法中可以放置assert校验输入参数,因为私有方法的使用者是作者自己,私有的方法的调用者和被调用者是一种契约关系,或者说没有契约关系,期间的约束是靠作者自己控制的,因此加上assert可以更好地预防自己犯错,或者无意的程序犯错。
  2. 流程控制中不可能到达的区域:这类似于Junit的fail方法,其标志性的意义就是,程序执行到这里就是错误的,例如:
public void doSomething() {
        int i = 7;
        while (i > 7) {
            /* 业务处理 */
        }
        assert false : "到达这里就表示错误";
    }

3.建立程序探针:我们可能会在一段程序中定义两个变量,分别代两个不同的业务含义,但是两者有固定的关系,例如:var1=var2 * 2,那我们就可以在程序中到处设"桩"了,断言这两者的关系,如果不满足即表明程序已经出现了异常,业务也就没有必要运行下去了。

建议20:不要只替换一个类

   我们经常在系统中定义一个常量接口(或常量类),以囊括系统中所涉及的常量,从而简化代码,方便开发,在很多的开源项目中已经采用了类似的方法,比如在struts2中,org.apache.struts2.StrutsConstants就是一个常量类,它定义Struts框架中与配置有关的常量,而org.apache.struts2.StrutsConstants则是一个常量接口,其中定义了OGNL访问的关键字。

  关于常量接口(类)我们开看一个例子,首先定义一个常量类:

public class Constant {
    //定义人类寿命极限
    public static final int MAX_AGE=150;
}

这是一个非常简单的常量类,定义了人类的最大年龄,我们引用这个常量,代码如下: 

public class Client{
    public static void main(String[] args) {
        System.out.println("人类的寿命极限是:"+Constant.MAX_AGE);
    }
}

  运行结果easy,故省略。目前的代码是写在"智能型"IDE工具中完成的,下面暂时回溯到原始时代,也就是回归到用记事本编写代码的年代,然后看看会发生什么事情(为什么要如此,下面会给出答案)

  修改常量Constant类,人类的寿命极限增加了,最大活到180,代码如下:

public class Constant {
    //定义人类寿命极限
    public static final int MAX_AGE=180;
}

  然后重新编译,javac Constant,编译完成后执行:java Client,大家猜猜输出的年龄是多少?

  输出的结果是:"人类的寿命极限是150",竟然没有改成180,太奇怪了,这是为何?

  原因是:对于final修饰的基本类型和String类型,编译器会认为它是稳定态的(Immutable Status)所以在编译时就直接把值编译到字节码中了,避免了在运行期引用(Run-time Reference),以提高代码的执行效率。对于我们的例子来说,Client类在编译时字节码中就写上了"150",这个常量,而不是一个地址引用,因此无论你后续怎么修改常量类,只要不重新编译Client类,输出还是照旧。

  对于final修饰的类(即非基本类型),编译器会认为它不是稳定态的(Mutable Status),编译时建立的则是引用关系(该类型也叫作Soft Final)。如果Client类引入的常量是一个类或实例,及时不重新编译也会输出最新值。

  千万不可小看了这点知识,细坑也能绊倒大象,比如在一个web项目中,开发人员修改了一个final类型的值(基本类型)考虑到重新发布的风险较大,或者是审批流程过于繁琐,反正是为了偷懒,于是直接采用替换class类文件的方式发布,替换完毕后应用服务器自动重启,然后简单测试一下,一切Ok,可运行几天后发现业务数据对不上,有的类(引用关系的类)使用了旧值,有的类(继承关系的类)使用的是新值,而且毫无头绪,让人一筹莫展,其实问题的根源就在于此。

  还有个小问题没有说明,我们的例子为什么不在IDE工具(比如Eclipse)中运行呢?那是因为在IDE中设置了自动编译不能重现此问题,若修改了Constant类,IDE工具会自动编译所有的引用类,"智能"化屏蔽了该问题,但潜在的风险其实仍然存在,我记得Eclipse应该有个设置自动编译的入口,有兴趣大家可以自己尝试一下。

  注意:发布应用系统时禁止使用类文件替换方式,整体WAR包发布才是万全之策。但我觉得应特殊情况特殊对待,并不可以偏概全,大家以为呢?

posted @ 2016-09-11 09:37  阿赫瓦里  阅读(4432)  评论(0编辑  收藏  举报