effective java 笔记4

from:http://blog.csdn.net/ilibaba/archive/2009/05/21/4207511.aspx

NO. 26 谨慎使用重载

一个常见的问题是:

public static String classify(Set s)

{ return “set”;}

public static String classify(List l)

{return “list”;}

public static String classify(Collection c)

{return “unknown collection”;}

public static void main(String[] args)

{ Collection[] tests=new Collection[]{

    new HashSet(), new ArrayList(), new HashMap.values()};

for(int i=0;i<tests.length;i++){System.out.println(classify(test[i]));}

程序结果是print出三个unknown collection。因为classify被重载了,到底调用哪个重载函数叔编译时刻决定的,因为编译时,大家的参数类型都是Collection。

避免方法重载机制的混淆。永远不要导出两个具有相同参数数目的重载方法,是一个安全而保守的策略。

至少应该保证,当传递同样的参数时,所有的重载方法行为一致。

NO.27 返回零长度的数组而不是null
    如果返回null,对于每次调用到该方法的时候都需要做null判断,否则很容易抛出空指针异常,推荐返回一个零长度的数组,在通常情况下,这样的做法对性能几乎没有影响。


NO.28 为所有导出的API元素编写文档注释
需要增加注释的地方:类、接口、构造函数、方法和域声明,

方法注释的内容:

调用该方法的前提条件;
调用后的后续处理(如捕获异常);
副作用(如方法启动线程后带来的安全性);
参数@param Describe;
返回@return Describe;
异常@throws  if.....;

注意:注释中可以适用<p><code><tt>等HTML标签,但>,<等标签需要转义。


NO.29 讲局部变量的作用域最小化
在第一次适用局部变量的地方声明他;(不要过早地声明它)
要防止局部变量在“使用它的块”之外声明,这样会防止局部变量被意外使用;
几乎每一个局部变量的需要初始化,如果没有足够的信息来对一个变量进行有意义的初始化,那就推迟这个声明,直到可以初始化为止;
其他的方法,例如,把一个变量多的方法分成两个,每次操作一个方法,减少变量之间的干扰。


NO.30 了解和使用库
    不要从头发明轮子,如果你要做的事情是很常见的,就去查下有没有这样的实现类,如果有,则使用它,这样会降低你实现相应功能的投入和代码的出错率。


NO.31 如果要求精确的答案,请避免使用 float和 double
      float和double不适合表示货币,在平时的使用中应该避免。

例如:System.out.println(1.00-9*.10); //会输出0.09999999999999998

如果希望系统来处理十进制的小数点,可以使用 BigDecimal。如果不考虑小数的处理,数值范围没有超过9位的则可以用int来处理,如果不超过18位的,则可以用long来处理,超过18位的就必须用 BigDecimal处理。


NO.32 如果其他类型更适合,则尽量避免使用字符串
    如果可以使用更加合适的数据类型,或者可以编写更加恰当的数据类型(如 DO、 POJO、枚举等),那么应该避免使用字符串来表示对象,若使用不当,字符串比其他类型更加笨拙,缺乏灵活性。


NO.33 了解字符串连接的性能
    为连接 N个字符串而重复得地使用“ +”连接,要消耗N的平方级别的时间。为了获得更高的性能,请使用 StringBuffer代替 String。


NO.34 通过接口引用对象
    应该优先使用接口而不是类来引用对象,如果有合适的接口存在,那么对参数的返回值、变量和域的声明都应该使用接口类型,如 Vector是List接口的实现,在声明时应该如下:

    List subscribers = new Vector();  

    //而不是

    Vector subscribers = new Vector(); 

例外的情况:

① 当没有合适的接口存在,可以用类而不是接口来引用一个对象,如: String、 Integer;

② 当一个对象是基本类型的类,而不是接口时,应该用相关的基类引用这个对象,如: java.util.TimerTask;

③ 当一个类实现了一个接口,但它提供了接口中不存在的额外方法,如果程序依赖于这些额外的方法,那么这样的类应该只被用来引用它的实例,永远不应该被用作参数类型。


NO.35 接口优先于映像机制(反射机制)
    反射机制是 Java一项强大的功能,给定一个class实例,你可以获得constructor、method和field实例。对于一些特定复杂的程序设计中非常必要(如现在很流行的 spring框架),但在并非必须使用反射机制时,尽量避免使用反射,原因如下:
     ① 它在编译时不会进行类型检查;
     ② 实现代码冗长乏味,不易阅读;
     ③ 性能与一般的方法调用相比,要低下很多;
    如果一个程序必须要与编译时未知的类一起工作,那么最好是用反射实例化对象,而访问对象时使用编译时刻已知的某个接口或者父类。


NO.36 谨慎地使用本地方法
    尽量使用 Java自身提供的方法来代替本地方法(如用 Java提供的新功能来代替以前只有 C语言能实现个的功能),这样可以使系统变得更加安全,系统可移植性更高,也使代码变得更加容易阅读,如果一定要使用本地方法,请加强测试,并尽可能的少用。


NO.37 谨慎地进行优化
    努力写好的程序而不是快的程序,程序要体现信息隐藏的原则,性能问题应该是设计阶段就考虑,要避免那些限制性能的设计决定,如:应该用复合模式的公有类使用继承,则该类的性能永久的受其父类性能的影响,为了获得好的性能而对 API进行修改并非是一个好的做法,通常,这些做法对性能并没什么多大的影响,如果一个系统有了清晰、简明、结构良好的实现,请谨慎对其进行优化,因为 80%的性能问题存在于 20%的代码中,找出影响性能的代码才是问题的关键,可以借助一些性能分析的工具。

 

第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 只针对不正常的条件才使用异常

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

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

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

其错有三:

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

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

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

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

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

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

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

 

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


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

  1. try{ 
  2.    ... 
  3. }catch(TheCheckedException e){ 
  4.    e.printStackTree(); 
  5.    System.exit(1); 

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

//Invocation with checked exception

  1. try{ 
  2.    obj.action(args); 
  3. }catch(TheCheckedException e){ 
  4. //Handle exception condition

转换为:

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

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

 

NO.42 尽量使用标准的异常
Java平台库中讫今为止最常被重用的异常如下:
IllegalArgumentException 参数值不合适
IllegalStateException 对于这个方法调用而言,对象的状态不合适(如初始化不恰当)
NullPointerException 在null被禁止的情况下参数值为null
IndexOutOfBoundsException 下标越界
ConcurrentModificationException 在禁止并发修改的情况下,对象检测到并发修改
UnsupportedOperationException 对象不支持客户请求的方法
其它的异常也可以使用,只要确保抛出异常的条件与文档要求一致即可。


NO.43 抛出的异常要适合于相应的抽象
高层的实现,应该捕获低层的异常,同时抛出一个可以按照高层抽象进行解释的异常,这种做法叫做异常转译(exception translation)。即如:

  1. //exception translation!
  2. try{ 
  3. //use lowlevel abstraction to do our bidding
  4.   ... 
  5. }catch(LowerLevelException e){ 
  6. throw new HigherLevelException(...); 

低层的异常被高层的异常保存起来,且高层的异常提供一个公有的访问方法来获得低层的异常,这种做叫做异常链接(exception chaining)。

  1. //Exception chaining.
  2. try{ 
  3. //use lower-level abstraction to do our bindding
  4.   ... 
  5. }catch(LowerLevelException e){ 
  6. throw new HigherLevelException(e); 

异常链的实现非常简单,在1.4及以后版本中,可以通过Throwable来获得支持。

  1. //Exception chaining in release 1.4 or later
  2. HigherLevelException(Throwable t){ 
  3. super(t); 

处理来自低层的异常,
最好的做法是,在调用低层方法之前通过一些检查等手段来确保它们会成功执行;
其次的做法是,让高层处理这些异常,从而将高层方法的调用者与低层的问题隔离开;
一般的做法是使用异常转译;
如果低层方法的异常对高层也是合适的,则将其从低层传到高层。


NO.44 每个方法抛出的异常都要有文档
      总是要单独地声明被检查的异常,并且利用javadoc的@throws标记,准确地记录下每个异常被抛出的条件。
      使用javadoc的@throws标签积累下一个方法可能会抛出的每个未被检查的异常,但是不要使用throws关键字将未被检查的异常包含在方法的声明中。
      如果一个类中的许多方法出于同样的原因而抛出同一个异常,那么在该类的文档注释中对这个异常做文档,而不是为每个方法单独写一个文档。


NO.45 在细节消息中包含失败 - 捕获信息
为了捕获失败,异常信息应该尽可能多的包含有意义的参数和域的值,如:IndexOutOfBoundsException应该包括上界、下界以及实际的下标。


NO.46 努力使失败保持原子性
      一个失败的方法调用应该使对象保持“它在被调用之前的状态”,方法如下:
① 使用非可变对象;
② 在可变对象上的操作,应在执行前检查参数的有效性;
③ 写一段恢复代码,在执行失败的情况下,回滚到操作开始之前的状态(不常用);
④ 在对象的一份临时拷贝上执行操作,当完成之后,再把临时拷贝中的结果复制给原来的对象,如Collections.sort在执行排序之前,先把它的输入转储到一个数组中,这样既能降低内循环的开销,又能保证在排序失败的时候,输入列表将保持原样。


NO.47 不要忽略异常
      除非有特殊的需求(如动画中的多帧图像播放),否则不要吃掉异常,至少在catch块中包含一条说明,用来解释为什么忽略这个异常。简单地将一个未被检查的异常传播到外界至少会使程序迅速地失败,从而保留了有助于调试该失败条件信息,比异常被忽略后的一个不可预测的时刻程序失败这种情况要强。

你可能感兴趣的:(Effective Java)