Set和Map中的类型安全

    原帖地址http://www.javablogging.com/type_safety_in_java_set_and_map/   

    也许你们大家都仍然记得在java1.4中类型检查和集合中元素的强制转型是多么麻烦，根本没法确定代码中有多少潜在的错误。由于在java1.5中通过泛型的说明这种状况确实得到改善，并且现在的语言开始照顾到了经常打错字的程序员。泛型自身给我们带来了一种新的复杂的设置，但是好像我们有理由相信基本情况下通过这种在java的Sets和Maps中使用，并不会带来类似通配符的并发症，转换应该是安全可靠的。真的是这样吗？

    最近我遇到了一个生产代码中的bug发生在一个简单的(真的很简单的)Map的应用中，令人尴尬的是我用很多方法去调试它，结果确实......唉......一个小问题。下面的代码演示了一个bug产生前代码的一个轮廓，在真实的生活中class中代码部分是很好的而且会经常修改的，肯定要比下面的代码多的多：

import java.util.HashMap;
import java.util.Map;

public class EmployeeDataLookup {
    // A map storing relation between employee ID and name.
    private Map<Integer, String> employeeIdToName;

    public EmployeeDataLookup() {
        // Create a new EmployeeDataLookup and initialize
        // it with employee names and IDs.
        employeeIdToName = new HashMap<Integer, String>();
        addEmployee(301, "John Doe");
        addEmployee(302, "Mary Poppins");
        addEmployee(303, "Andy Stevens");
    }

    public void addEmployee(int employeeId, String employeeName) {
        employeeIdToName.put(employeeId, employeeName);
    }

    // This class is very complicated and has many other methods...

    // Lookup method for finding employee name for given employee ID.
    public String findEmployeeName(int employeeId) {
        return employeeIdToName.get(employeeId);
    }

    public static void main(String[] args) {
        // Create a EmployeeDataLookup instance
        EmployeeDataLookup employeeLookup = new EmployeeDataLookup();
        // Find the name of an employee with ID = 301
        String employeeName = employeeLookup.findEmployeeName(301);
        System.out.print("Employee 301 : " + employeeName);
    }
}

    这有什么问题呢？哦，在一个项目中功能要求发生了变化(有点惊讶，是吧？)和Map中Key的内部数据必须发生了变化。例如公司是合并的供应商之一，因此系统存储employee数据必须做出跟供应商ID兼容的例子。由于供应商用的是13位的IDs,所以我们必须java代码中Integer替换成Long。简单吧？着看起来很简单，我们用类似于eclipse的ide的重构--只要改变第7行的Map key的定义Integer变为Long，让编辑器显示所有的错误，然后修复他们！五分钟搞定：

import java.util.HashMap;
import java.util.Map;

public class EmployeeDataLookup2 {
    // A map storing relation between employee ID and name.
    private Map<Long, String> employeeIdToName;

    public EmployeeDataLookup2() {
        // Create a new EmployeeDataLookup and initialize
        // it with employee names and IDs.
        employeeIdToName = new HashMap<Long, String>();
        addEmployee(301, "John Doe");
        addEmployee(302, "Mary Poppins");
        addEmployee(303, "Andy Stevens");
    }

    public void addEmployee(long employeeId, String employeeName) {
        employeeIdToName.put(employeeId, employeeName);
    }

    // This class is very complicated and has many other methods...

    // Lookup method for finding employee name for given employee ID.
    public String findEmployeeName(int employeeId) {
        return employeeIdToName.get(employeeId);
    }

    public static void main(String[] args) {
        // Create a EmployeeDataLookup instance
        EmployeeDataLookup employeeLookup = new EmployeeDataLookup();
        // Find the name of an employee with ID = 301
        String employeeName = employeeLookup.findEmployeeName(301);
        System.out.print("Employee 301 : " + employeeName);
    }
}

    这段改变导致了一个错误，你能发现吗？当您运行main方法的时候你会发现，该员工的ID=301的值是“null”，哈！

    如果没有发现个问题（或者懒得去尝试）我给你一个提示是去检查25行和26行，如果你能发现它，我们尝试想一下现实生活中的class有1000+的代码和不确定的要改变的Map，由于我们没有编译错误，我们就像大海捞针一样找它，这为什么产生这个bug。

    这个问题是在引入了泛型，可能为了向后兼容，一些方法在Collection and Map interface 并没有修改和仍然没有进行类型检查。其中一个我们发现的方法就是Map.get(Object)导致我们上面的错误。经过“简单修改”后我们仍然用Interger keys去访问包含了Long类型的Map，所以我们即使是有301的employee仍然get返回null，而且由于缺乏类型检查并没有警告......

    那么我们能得到上面教训？要谨慎关于基本情况，甚至类型检查。记住那些访问方法在Sets,Lists和Maps可能伤害你，最大的痛苦是通过这种方式产生的bug很被人识别，有时候甚至十几人对着代码都难找出它。有一个办法可以找到他们——如果你正在使用静态代码分析工具，大部分这样的bug都可以很容易被识别(如：findBUGs)。