来指导初学者。其中一个任务是要求大家完成一个类，要求类对一个key为String类型的map进行dwarwle操作。在其中一名学生完成的课程中，有以下方法：getKey(),entry.getValue(),dwarwleKey);}}这段代码一般就OK了。此方法将映射中每个Dwarable的键和值，连同它期望被反汇编的dwarwleKey一起传递给另一个调用方法。因为功能简单，就不详细描述了。只要理解了dwarwle的意思，就可以很容易的知道这个方法会做什么。这样的函数简单，可读性好。但是，此方法期望参数是HashMap，而不是Map。这里为什么要强制调用者使用HashMap呢？如果调用者因为某种原因需要使用TreeMap，是否需要再增加一个同样的方法来接受TreeMap？当然不是。“参数类型使用接口，调用时传入实现接口的对象。”这个初学者使用Map而不是HashMap。但是大约5分钟后，这位聪明的女士又问了这个问题：“如果我们把HashMap换成Map，为什么不把String换成CharSequence呢？”突然间回答这样的问题就没那么容易了。我首先想到的是，我们通常会这样做，这就是原因。但是这个回答一点说服力都没有，至少我不会接受这样的回答，希望我的学生也不要接受这样的回答。这是一种非常专制的回答方式。真正的答案是因为这个参数是作为Map的key使用的，而通常期望Map的key是不可变的（至少变化不会影响equals和hashCode的计算）。CharSequence是一个接口，Java并没有规定接口的可变性，只有具体的实现才能决定。String是CharSequence的具体实现，广为人知并经过严格测试，因此在这里是一个不错的选择。在这个具体的例子中，我们更倾向于String，因为它是不可变的（Immutable）。我们不能完全相信调用者会传递CharSequence的不可变具体实现。如果我们可以信任来电者，那么我们可能会付出代价。当StringBuilder作为参数传递给这个方法时，它的值稍后发生变化，我们编写的类库可能无法工作。在设计一个API或者类库的时候，我们需要考虑的不仅仅是我们期望的一些可能性，还有现实中的各种可能性。“实践是检验真理的最好标准。”不限于类库，这也可能适用于其他产品。这似乎太过分了。原文链接：javacodegeeks翻译：ImportNew.com-nealjob翻译链接：http://www.importnew.com/13664.html
