Effective Java 笔记（十）

相关读书笔记列表

第38条：遵守普遍接受的命名惯例
java的命名惯例分为两大类：字面的和语法的。 字面命名惯例涉及包、类、接口、方法和域。 包的名字是层次结构的，用句号分隔第一部分。每一部分的长度不要超过8，由小写字母和数字组成（数字少见用），鼓励使用有意义的缩写。除了java和javax外，一般以域名做开头，顺序是顶级域名放在最前面。 类和接口的名字应至少1至多个单词，每个单词的首字母大写（驼峰试)，尽量避免缩写。

方法和域的名字与类和接口的名字遵守相同的字面惯例，只是第一个首字母要小写。常量域要全部字母都大写，词之间通过下划线区分。

语法命名惯例比字面惯例更灵活。

1. 类通常用一个名词或名词短语，接口或者与类相同，或者以"-able"或"-ible"结尾的形容词。
2. 执行某个动作的方法，常用一个动词或动词短语，
3. 对于返回boolean类型的方法，名字常以“is"开头后加一个名词或形容词或短语，
4. 如果返回的不是boolean，则常用一个名词/短语，或以"get"开头的动词短语。
5. 如果一方法所在的类是一个Bean，则强制要求以get开头。
6. 如果类包含对属性操作，常用setAttribute或getAttribute格式命名。

转换对象类型的方法，

1. 如果返回不同类型的独立的对象，则称为toType
2. 如果返回一个视图，则用asType,
3. 如果返回与被调用对象同值的原语类型，称为typeValue
4. 静态工厂的方法，常用valueOf或getInstance.

NO.39 只针对不正常的条件才使用异常

异常只应该被用于不正常的条件，它们永远不应被用于正常的控制流。

下面是一个用异常作遍历结束条件的滥用异常的例子：

//horrible abuse of exceptions. Don't ever do this!
try{
  int i=0;
  while(true)a[i++].f();
}catch(ArrayIndexOutOfBoundsException e){
  ...
}

其错有三：

1、创建、抛出和捕获异常的开销是很昂贵的。因为它的初衷是用于不正常的情形，少有jvm会它进行性能优化。

2、把代码放在try-catch中会阻止jvm实现本来可能要执行的某些特定的优化。

3、有些现代的jvm对循环进行优化，不会出现冗余的检查。

完全可以使用标准的实现方式：

for(int i=0;i<a.length;i++){
    a[i].f();
}

　　这条原则也适用于API设计。一个设计良好的API不应该强迫它的客户为了正常的控制流而使用异常。如果类中有一个”状态相关”的方法，即只有 特定的条件下可被调用的方法，则这个类也应有一个单独的“状态测试”方法，以为调用这个状态相关方法前的检查。如Collection类的next方法和 hasNext方法。

for(Iterator i=collection.iterator();i.hasNext();){
    Foo foo=(Foo)i.next();
    ...
}

第40条：对于可恢复的条件使用被检查的异常，对于程序错误使用运行时异常
java提供了三种可抛出的异常：被检查的异常（checkedException）、运行时异常（run-time Exception）和错误(error)。 　　如果期望调用者在调用时出现的异常能够恢复，则应该使用被检查的异常，通过抛出一个被检查的异常，强迫调用者在catch中处理该异常，或者将异常传播到外面。
　　对于一个方法声明要抛出的每一个被检查的异常，它是对API用户的一种潜在指示：与异常相关联的条件是调用这次个方法的一种可能结果。
　 　两种未被检查的可抛出结构：运行时异常和错误，在行为上相同的，它们都不需要、也不应该被捕获的抛出物。你所实现的所有未被检查的抛出结构都应是 RuntimeException的子类。定义一个非Exception、RuntimeException或Error子类的抛出物是可行的，但从行为 意义上它等同于被普通的被检查异常（即Exception子类而非RuntimeException子类）.
　　异常是个完全意义上的对象，在其上可以定义任意的方法。因被检查的异常往往指示了可恢复的条件，所以可通过定义方法，使调用者可获得一些有助于恢复的信息。具体可参见“Java异常的分类”

NO.41 避免不必要地使用被检查的异常
与返回代码不同，被检查的异常强迫程序处理例外的情况，从而大大地提高了程序的可靠性。而过分地使用被检查的异常，则增加了不可忽视的负担。如果正 确地使用API并不能阻止这种异常条件的产生，并且一旦产生了异常，使用API的程序可以采取有用的动作，那么这种负担被认为是正当的。

try{
   ...
}catch(TheCheckedException e){
   e.printStackTree();
   System.exit(1);
}

　　如果使用API的程序员无法做得比这更好，那么未被检查的异常可能更为合适。在实践中，catch几乎总有断言失败的特征。
　　“把被检查的异常变成未被检查的异常”的一种技术是，把这个要抛出异常的方法分成两个方法，第一个方法返回一个boolean以指明是否要抛出异常，另一个执行真正的功能，如果条件不满足就抛异常。如下：

//Invocation with checked exception
try{
   obj.action(args);
}catch(TheCheckedException e){
   //Handle exception condition
}

　　转换为：

//Invocation with state-testing method and unchecked exception
if(obj.actionPermitted(args)){
   obj.action(args));
}else{
   //handle exception condition
}

　　当然这种转换并不总是合适的，例如一对象将在缺少外部同步的情况下被并发访问，或者可被外界改变状态，那么这种转换将是不合适的。