首页 > 代码库 > 转载--编写高质量代码:改善Java程序的151个建议(第1章:JAVA开发中通用的方法和准则___建议11~15)
转载--编写高质量代码:改善Java程序的151个建议(第1章:JAVA开发中通用的方法和准则___建议11~15)
阅读目录
- 建议11：养成良好习惯，显示声明UID
- 建议12：避免用序列化类在构造函数中为不变量赋值
- 建议13：避免为final变量复杂赋值
- 建议14：使用序列化类的私有方法巧妙解决部分属性持久化问题
- 建议15：break万万不可忘
建议11：养成良好习惯，显示声明UID
我们编写一个实现了Serializable接口（序列化标志接口）的类，Eclipse马上就会给一个黄色警告：需要添加一个Serial Version ID。为什么要增加？他是怎么计算出来的？有什么用?下面就来解释该问题。
类实现Serializable接口的目的是为了可持久化，比如网络传输或本地存储，为系统的分布和异构部署提供先决条件支持。若没有序列化，现在我们熟悉的远程调用、对象数据库都不可能存在，我们来看一个简单的序列化类：
1 import java.io.Serializable;
2 public class Person implements Serializable {
3 private String name;
4
5 public String getName() {
6 return name;
7 }
8
9 public void setName(String name) {
10 this.name = name;
11 }
12
13 }
这是一个简单的JavaBean，实现了Serializable接口，可以在网络上传输，也可以在本地存储然后读取。这里我们以java消息服务(Java Message Service)方式传递对象（即通过网络传递一个对象），定义在消息队列中的数据类型为ObjectMessage，首先定义一个消息的生产者（Producer）,代码如下:
1 public class Producer {
2 public static void main(String[] args) {
3 Person p = new Person();
4 p.setName("混世魔王");
5 // 序列化，保存到磁盘上
6 SerializationUtils.writeObject(p);
7 }
8 }
这里引入了一个工具类SerializationUtils，其作用是对一个类进行序列化和反序列化，并存储到硬盘上（模拟网络传输），其代码如下：
1 import java.io.FileInputStream;
2 import java.io.FileNotFoundException;
3 import java.io.FileOutputStream;
4 import java.io.IOException;
5 import java.io.ObjectInputStream;
6 import java.io.ObjectOutputStream;
7 import java.io.Serializable;
8
9 public class SerializationUtils {
10 private static String FILE_NAME = "c:/obj.bin";
11 //序列化
12 public static void writeObject(Serializable s) {
13 try {
14 ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream(FILE_NAME));
15 oos.writeObject(s);
16 oos.close();
17 } catch (FileNotFoundException e) {
18 e.printStackTrace();
19 } catch (IOException e) {
20 e.printStackTrace();
21 }
22 }
23 //反序列化
24 public static Object readObject() {
25 Object obj = null;
26 try {
27 ObjectInputStream input = new ObjectInputStream(new FileInputStream(FILE_NAME));
28 obj=input.readObject();
29 input.close();
30 } catch (FileNotFoundException e) {
31 e.printStackTrace();
32 } catch (IOException e) {
33 e.printStackTrace();
34 } catch (ClassNotFoundException e) {
35 e.printStackTrace();
36 }
37 return obj;
38 }
39 }
通过对象序列化过程，把一个内存块转化为可传输的数据流，然后通过网络发送到消息消费者（Customer）哪里，进行反序列化，生成实验对象，代码如下：
1 public class Customer {
2 public static void main(String[] args) {
3 //反序列化
4 Person p=(Person) SerializationUtils.readObject();
5 System.out.println(p.getName());
6 }
7 }
这是一个反序列化的过程，也就是对象数据流转换为一个实例的过程，其运行后的输出结果为“混世魔王”。这太easy了,是的，这就是序列化和反序列化的典型Demo。但此处藏着一个问题：如果消息的生产者和消息的消费者（Person类）有差异，会出现何种神奇事件呢？比如：消息生产者中的Person类添加一个年龄属性，而消费者没有增加该属性。为啥没有增加？因为这个是分布式部署的应用，你甚至不知道这个应用部署在何处，特别是通过广播方式发消息的情况，漏掉一两个订阅者也是很正常的。
这中序列化和反序列化的类在不一致的情况下，反序列化时会报一个InalidClassException异常，原因是序列化和反序列化所对应的类版本发生了变化，JVM不能把数据流转换为实例对象。刨根问底：JVM是根据什么来判断一个类的版本呢？
好问题，通过SerializableUID，也叫做流标识符（Stream Unique Identifier），即类的版本定义的，它可以显示声明也可以隐式声明。显示声明格式如下：
private static final long serialVersionUID = 1867341609628930239L;
而隐式声明则是我不声明，你编译器在编译的时候帮我生成。生成的依据是通过包名、类名、继承关系、非私有的方法和属性，以及参数、返回值等诸多因子算出来的，极度复杂，基本上计算出来的这个值是唯一的。
serialVersionUID如何生成已经说明了，我们再来看看serialVersionUID的作用。JVM在反序列化时，会比较数据流中的serialVersionUID与类的serialVersionUID是否相同，如果相同，则认为类没有改变，可以把数据load为实例相同；如果不相同，对不起，我JVM不干了，抛个异常InviladClassException给你瞧瞧。这是一个非常好的校验机制，可以保证一个对象即使在网络或磁盘中“滚过”一次，仍能做到“出淤泥而不染”，完美的实现了类的一致性。
但是，有时候我们需要一点特例场景，例如我的类改变不大，JVM是否可以把我以前的对象反序列化回来？就是依据显示声明的serialVersionUID，向JVM撒谎说"我的类版本没有变化"，如此我买你编写的类就实现了向上兼容，我们修改Person类,里面添加private static final long serialVersionUID = 1867341609628930239L;
刚开始生产者和消费者持有的Person类一致，都是V1.0，某天生产者的Person类变更了，增加了一个“年龄”属性，升级为V2.0，由于种种原因（比如程序员疏忽，升级时间窗口不同等）消费端的Person类还是V1.0版本，添加的代码为 priavte int age;以及对应的setter和getter方法。
此时虽然生产这和消费者对应的类版本不同，但是显示声明的serialVersionUID相同，序列化也是可以运行的，所带来的业务问题就是消费端不能读取到新增的业务属性(age属性而已)。通过此例，我们反序列化也实现了版本向上兼容的功能，使用V1.0版本的应用访问了一个V2.0的对象，这无疑提高了代码的健壮性。我们在编写序列化类代码时随手添加一个serialVersionUID字段，也不会带来太多的工作量，但它却可以在关键时候发挥异乎寻常的作用。
显示声明serialVersionUID可以避免对象的不一致，但尽量不要以这种方式向JVM撒谎。
建议12：避免用序列化类在构造函数中为不变量赋值
我们知道带有final标识的属性是不变量，也就是只能赋值一次，不能重复赋值，但是在序列化类中就有点复杂了，比如这个类：
1 public class Person implements Serializable {
2 private static final long serialVersionUID = 1867341609628930239L;
3 public final String perName="程咬金";
4 ｝
这个Peson类（此时V1.0版本）被序列化，然后存储在磁盘上，在反序列化时perName属性会重新计算其值(这与static变量不同，static变量压根就没有保存到数据流中)比如perName属性修改成了"秦叔宝"(版本升级为V2.0)，那么反序列化的perName值就是"秦叔宝"。保持新旧对象的final变量相同，有利于代码业务逻辑统一，这是序列化的基本原则之一，也就是说，如果final属性是一个直接量，在反序列化时就会重新计算。对于基本原则不多说，现在说一下final变量的另一种赋值方式：通过构造函数赋值。代码如下:
public class Person implements Serializable {
private static final long serialVersionUID = 1867341609628930239L;
public final String perName;
public Person() {
perName = "程咬金";
}
}
这也是我们常用的一种赋值方式，可以把Person类定义为版本V1.0，然后进行序列化，看看序列化后有什么问题,序列化代码如下:
public class Serialize {
public static void main(String[] args) {
//序列化以持久保持
SerializationUtils.writeObject(new Person());
}
}
Person的实习对象保存到了磁盘上，它时一个贫血对象(承载业务属性定义，但不包含其行为定义)，我们做一个简单的模拟，修改一下PerName值代表变更，要注意的是serialVersionUID不变，修改后的代码如下：
public class Person implements Serializable {
private static final long serialVersionUID = 1867341609628930239L;
public final String perName;
public Person() {
perName = "秦叔宝";
}
}
此时Person类的版本时V2.0但serialVersionUID没有改变，仍然可以反序列化，代码如下:
public class Deserialize {
public static void main(String[] args) {
Person p = (Person) SerializationUtils.readObject();
System.out.println(p.perName);
}
}
现在问题出来了，打印出来的结果是"程咬金" 还是"秦叔宝"？答案是:"程咬金"。final类型的变量不是会重新计算嘛，打印出来的应该是秦叔宝才对呀。为什么会是程咬金？这是因为这里触及到了反序列化的两一个原则:反序列化时构造函数不会执行.
反序列化的执行过程是这样的：JVM从数据流中获取一个Object对象，然后根据数据流中的类文件描述信息(在序列化时，保存到磁盘的对象文件中包含了类描述信息，注意是描述信息，不是类)查看，发现是final变量，需要重新计算，于是引用Person类中的perName值，而此时JVM又发现perName竟没有赋值，不能引用，于是它很聪明的不再初始化，保持原值状态，所以结果就是"程咬金"了。
注意：在序列化类中不使用构造函数为final变量赋值.
建议13：避免为final变量复杂赋值
为final变量赋值还有另外一种方式：通过方法赋值，及直接在声明时通过方法的返回值赋值，还是以Person类为例来说明，代码如下:
public class Person implements Serializable {
private static final long serialVersionUID = 1867341609628930239L;
//通过方法返回值为final变量赋值
public final String pName = initName();
public String initName() {
return "程咬金";
}
}
pName属性是通过initName方法的返回值赋值的，这在复杂的类中经常用到，这比使用构造函数赋值更简洁，易修改，那么如此用法在序列化时会不会有问题呢？我们一起看看。Person类写好了（定义为V1.0版本），先把它序列化，存储到本地文件，其代码与之前相同，不在赘述。现在Person类的代码需要修改，initName的返回值改为"秦叔宝".那么我们之前存储在磁盘上的的实例加载上来，pName的会是什么呢？
现在,Person类的代码需要修改，initName的返回值也改变了，代码如下:
public class Person implements Serializable {
private static final long serialVersionUID = 1867341609628930239L;
//通过方法返回值为final变量赋值
public final String pName = initName();
public String initName() {
return "秦叔宝";
}
}
上段代码仅仅修改了initName的返回值(Person类为V2.0版本)也就是通过new生成的对象的final变量的值都是"秦叔宝"，那么我们把之前存储在磁盘上的实例加载上来，pName的值会是什么呢？
结果是"程咬金"，很诧异，上一建议说过final变量会被重新赋值，但是这个例子又没有重新赋值，为什么？
上个建议说的重新赋值，其中的"值"指的是简单对象。简单对象包括：8个基本类型，以及数组、字符串(字符串情况复杂，不通过new关键字生成的String对象的情况下，final变量的赋值与基本类型相同)，但是不能方法赋值。
其中的原理是这样的，保存到磁盘上(或网络传输)的对象文件包括两部分:
(1).类描述信息：包括类路径、继承关系、访问权限、变量描述、变量访问权限、方法签名、返回值、以及变量的关联类信息。要注意一点是，它并不是class文件的翻版，它不记录方法、构造函数、static变量等的具体实现。之所以类描述会被保存，很简单，是因为能去也能回嘛，这保证反序列化的健壮运行。
(2).非瞬态(transient关键字)和非静态(static关键字)的实体变量值
注意，这里的值如果是一个基本类型，好说，就是一个简单值保存下来；如果是复杂对象，也简单，连该对象和关联类信息一起保存，并且持续递归下去（关联类也必须实现Serializable接口，否则会出现序列化异常），也就是递归到最后，还是基本数据类型的保存。
正是因为这两个原因，一个持久化的对象文件会比一个class类文件大很多，有兴趣的读者可以自己测试一下，体积确实膨胀了不少。
总结一下：反序列化时final变量在以下情况下不会被重新赋值:
- 通过构造函数为final变量赋值
- 通过方法返回值为final变量赋值
- final修饰的属性不是基本类型
建议14：使用序列化类的私有方法巧妙解决部分属性持久化问题
部分属性持久化问题看似很简单，只要把不需要持久化的属性加上瞬态关键字(transient关键字)即可。这是一种解决方案，但有时候行不通。例如一个计税系统和一个HR系统，通过RMI(Remote Method Invocation,远程方法调用)对接，计税系统需要从HR系统获得人员的姓名和基本工资，以作为纳税的依据，而HR系统的工资分为两部分：基本工资和绩效工资，基本工资没什么秘密，绩效工资是保密的，不能泄露到外系统，这明显是连个相互关联的类，先看看薪水类Salary的代码：
1 public class Salary implements Serializable {
2 private static final long serialVersionUID = 2706085398747859680L;
3 // 基本工资
4 private int basePay;
5 // 绩效工资
6 private int bonus;
7
8 public Salary(int _basepay, int _bonus) {
9 this.basePay = _basepay;
10 this.bonus = _bonus;
11 }
12 //Setter和Getter方法略
13
14 }
Person类和Salary类是关联关系，代码如下:
1 public class Person implements Serializable {
2
3 private static final long serialVersionUID = 9146176880143026279L;
4
5 private String name;
6
7 private Salary salary;
8
9 public Person(String _name, Salary _salary) {
10 this.name = _name;
11 this.salary = _salary;
12 }
13
14 //Setter和Getter方法略
15
16 }
这是两个简单的JavaBean，都实现了Serializable接口，具备了序列化的条件。首先计税系统请求HR系统对一个Person对象进行序列化，把人员信息和工资信息传递到计税系统中，代码如下:
1 public class Serialize {
2 public static void main(String[] args) {
3 // 基本工资1000元，绩效工资2500元
4 Salary salary = new Salary(1000, 2500);
5 // 记录人员信息
6 Person person = new Person("张三", salary);
7 // HR系统持久化,并传递到计税系统
8 SerializationUtils.writeObject(person);
9 }
10 }
在通过网络传输到计税系统后，进行反序列化，代码如下：
1 public class Deserialize {
2 public static void main(String[] args) {
3 Person p = (Person) SerializationUtils.readObject();
4 StringBuffer buf = new StringBuffer();
5 buf.append("姓名: "+p.getName());
6 buf.append("\t基本工资: "+p.getSalary().getBasePay());
7 buf.append("\t绩效工资: "+p.getSalary().getBonus());
8 System.out.println(buf);
9 }
10 }
打印出的结果为:姓名: 张三 基本工资: 1000 绩效工资: 2500
但是这不符合需求，因为计税系统只能从HR系统中获取人员姓名和基本工资，而绩效工资是不能获得的，这是个保密数据，不允许发生泄漏。怎么解决这个问题呢？你可能会想到以下四种方案:
- 在bonus前加上关键字transient：这是一个方法，但不是一个好方法，加上transient关键字就标志着Salary失去了分布式部署的功能，它可能是HR系统核心的类了，一旦遭遇性能瓶颈，再想实现分布式部署就可能了，此方案否定;
- 新增业务对象：增加一个Person4Tax类，完全为计税系统服务，就是说它只有两个属性：姓名和基本工资。符合开闭原则，而且对原系统也没有侵入性，只是增加了工作量而已。但是这个方法不是最优方法;
- 请求端过滤：在计税系统获得Person对象后，过滤掉Salary的bonus属性，方案可行但不符合规矩，因为HR系统中的Salary类安全性竟然然外系统(计税系统来承担)，设计严重失职;
- 变更传输契约：例如改用XML传输，或者重建一个WebSerive服务，可以做但成本很高。
下面展示一个优秀的方案，其中实现了Serializable接口的类可以实现两个私有方法：writeObject和readObject，以影响和控制序列化和反序列化的过程。我们把Person类稍作修改，看看如何控制序列化和反序列化，代码如下:
1 public class Person implements Serializable {
2
3 private static final long serialVersionUID = 9146176880143026279L;
4
5 private String name;
6
7 private transient Salary salary;
8
9 public Person(String _name, Salary _salary) {
10 this.name = _name;
11 this.salary = _salary;
12 }
13 //序列化委托方法
14 private void writeObject(ObjectOutputStream oos) throws IOException {
15 oos.defaultWriteObject();
16 oos.writeInt(salary.getBasePay());
17 }
18 //反序列化委托方法
19 private void readObject(ObjectInputStream input)throws ClassNotFoundException, IOException {
20 input.defaultReadObject();
21 salary = new Salary(input.readInt(), 0);
22 }
23 }
其它代码不做任何改动，运行之后结果为：姓名: 张三 基本工资: 1000 绩效工资: 0
在Person类中增加了writeObject和readObject两个方法，并且访问权限都是私有级别，为什么会改变程序的运行结果呢？其实这里用了序列化的独有机制：序列化回调。Java调用ObjectOutputStream类把一个对象转换成数据流时，会通过反射（Refection）检查被序列化的类是否有writeObject方法，并且检查其是否符合私有，无返回值的特性，若有，则会委托该方法进行对象序列化，若没有，则由ObjectOutputStream按照默认规则继续序列化。同样，在从流数据恢复成实例对象时，也会检查是否有一个私有的readObject方法，如果有，则会通过该方法读取属性值，此处有几个关键点需要说明：
- oos.defaultWriteObject():告知JVM按照默认的规则写入对象，惯例的写法是写在第一行。
- input.defaultReadObject():告知JVM按照默认规则读入对象，惯例的写法是写在第一行。
- oos.writeXX和input.readXX
分别是写入和读出相应的值，类似一个队列，先进先出，如果此处有复杂的数据逻辑，建议按封装Collection对象处理。大家可能注意到上面的方式也是Person失去了分布式部署的能了，确实是，但是HR系统的难点和重点是薪水的计算，特别是绩效工资，它所依赖的参数很复杂（仅从数量上说就有上百甚至上千种），计算公式也不简单(一般是引入脚本语言，个性化公式定制)而相对来说Person类基本上都是静态属性，计算的可能性不大，所以即使为性能考虑，Person类为分布式部署的意义也不大。
建议15：break万万不可忘
我们经常会写一些转换类，比如货币转换，日期转换，编码转换等，在金融领域里用到的最多的要数中文数字转换了，比如把"1"转换为"壹" ，不过开源工具是不会提供此工具类的，因为它太贴近中国文化了，需要自己编写：
1 public class Client15 {
2 public static void main(String[] args) {
3 System.out.println(toChineseNuberCase(0));
4 }
5
6 public static String toChineseNuberCase(int n) {
7 String chineseNumber = "";
8 switch (n) {
9 case 0:
10 chineseNumber = "零";
11 case 1:
12 chineseNumber = "壹";
13 case 2:
14 chineseNumber = "贰";
15 case 3:
16 chineseNumber = "叁";
17 case 4:
18 chineseNumber = "肆";
19 case 5:
20 chineseNumber = "伍";
21 case 6:
22 chineseNumber = "陆";
23 case 7:
24 chineseNumber = "柒";
25 case 8:
26 chineseNumber = "捌";
27 case 9:
28 chineseNumber = "玖";
29 }
30 return chineseNumber;
31 }
32 }
这是一个简单的代码，但运行结果却是"玖"，这个很简单，可能大家在刚接触语法时都学过，但虽简单，如果程序员漏写了，简单的问题会造成很大的后果，甚至经济上的损失。所以在用switch语句上记得加上break，养成良好的习惯。对于此类问题，除了平常小心之外，可以使用单元测试来避免，但大家都晓得，项目紧的时候，可能但单元测试都覆盖不了。所以对于此类问题，一个最简单的办法就是：修改IDE的警告级别，例如在Eclipse中，可以依次点击PerFormaces-->Java-->Compiler-->Errors/Warings-->Potential Programming problems,然后修改‘switch‘ case fall-through为Errors级别，如果你胆敢不在case语句中加入break，那Eclipse直接就报个红叉给你看，这样可以避免该问题的发生了。但还是啰嗦一句，养成良好习惯更重要!
转载--编写高质量代码:改善Java程序的151个建议(第1章:JAVA开发中通用的方法和准则___建议11~15)