Effective Java : 方法

38.检查参数的有效性

不检查

如果不对参数进行检查,可能会出现如下错误:

处理过程中发生失败,产生令人费解的异常

正常返回,但是会计算出错误的结果

能正常返回,但是破坏了某个状态,在不确定的将来某个节点上引发错误(相当不好定位)

正确的做法

早 javadoc 的 @throws 标签文档中进行说明.(如果违反了参数限制将抛出异常)

在计算任务之前,就应该先检查他的参数

如果计算过程抛出异常,已改使用

异常转译

技术,

39.必要时进行保护性拷贝

简介

Java 是一门 安全的语言.对于 缓冲区溢出,数组越界,非法指针等内存错误都会自动免疫.\

在下列情况下,需要对类的健壮性做一些工作.

有人视图破坏这个类的约束条件时.

对API产生误解的程序员,所导致的不可预期的行为.

如下这个类: Period.java

保护性拷贝的重要性

可以通过如下方式破坏实例的

内部信息.

Date start = new Date();
Date end = new Date();
Period period = new Period(start,end);
end.setYear(78);//改变了end对象,造成内部错误

为了避免 受到这种攻击,可以对参数的每个可变参数进行

保护性拷贝

,并且使用拷贝后的对象,如下:

public Period(Date start, Date end) {
if (start.compareTo(end) > 0)
throw new IllegalArgumentException(start + " after " + end);
this.start = new Date(start.getTime());
this.end = new Date(end.getTime()); //使用的是拷贝对象,这样的话,就不怕上面的改变了,因为不会改变内部对象.
}

注意事项

在 38 条中,我们说要对

参数进行有效性检查

,检查也是发生在保护性拷贝之后的/

对于参数类型,可以

被不可信任方

子类化

的参数,不要使用

clone

来实现保护性拷贝.

采用新的访问方式,可以提高 类型的

不可变能力

public Date start(){
return new Date(start.getTime());
}

如果有可能,应该使用不可变对象作为类的内部组件,这样就不用考虑

保护性拷贝

了

40.谨慎设计方法签名

设计原则:

谨慎的选择方法名称

不要过于追求提供便利的方法

避免过长的参数列表,可以有如下三种方式

把方法分解为多个方法,每个方法只需要参数列表的一个子集.

创建辅助类,用于保存参数的分组

采用

Builder

模式.

对于参数类型,优先考虑

接口

而

不是类

对于

Boolean

,要优先使用

两个元素

的`枚举类型,如下所示

public enum TemperatureScale{FAHRENHRIT,CELSIUS;}

41.慎用重载

示例

首先来看一个示例:

public class CollectionClassifier {
public static String classify(Set<?> s) {
return "Set";
}
public static String classify(List<?> lst) {
return "List";
}
public static String classify(Collection<?> c) {
return "Unknown Collection";
}

public static void main(String[] args) {
Collection<?>[] collections = { new HashSet<String>(),
new ArrayList<BigInteger>(),
new HashMap<String, String>().values() };
//打印了三次 Unknown Collection
for (Collection<?> c : collections)
System.out.println(classify(c));//这里并不会按照我们期望的那样选择调用某一个 重载方法
}
}

因为要 调用 哪个重载方法是在编译时确定的.虽然运行时是不同的.

再看另一个示例:

class Wine {
String name() {
return "wine";
}
}
class SparklingWine extends Wine {
@Override
String name() {
return "sparkling wine";
}
}
class Champagne extends SparklingWine {
@Override
String name() {
return "champagne";
}
}

public class Overriding {
public static void main(String[] args) {
Wine[] wines = { new Wine(), new SparklingWine(), new Champagne() };
//打印出了 wine,sparkling wine,champagne
for (Wine wine : wines)
System.out.println(wine.name());
}
}

这里就不会出现上面的问题,因为对于

重载方法

的选择是

静态的

,对于

重写方法

的选择则是

动态的

对于第一个示例中,我们通过如下方式修正:

public static String classify(Collection<?> c){
return c instanceof Set?"Set":c instanceof List?"List":"Unknown Collection";
}

建议

永远不要到处两个

具有相同参数数目的

重载方法.

如果是可变参数,保守策略是

永远不要重载它

对于每一对 重载方法,应

保持

方法中具有

根本不同的类型

(像上面的

List

和

Collection

在根本上是由关系的 ) |

如果两个类都不是对方的后代,则是不相关的

.

包装类引起的误会

比如如下示例:

Set<Integer> set = new TreeSet<Integer>();
List<Integer> list = new ArrayList<Integer>();
for (int i = -3; i < 3; i++) {
set.add(i);
list.add(i);
}
for (int i = 0; i < 3; i++) {
// 这里调用的是 Set#remove(E),//set.remove(Integer);
set.remove(i);
//而这里确是List#remove(i),
list.remove(i);
}

为了修正上面的错误,可以使用

list.remove(Integer.valueOf(i));

这里就是 自动装箱 引起的错误.

小结

简而言之,

对于多个具有相同参数数目的方法来说,应尽量避免重载

对于构造器,如果不能避免,应该保证传递同样的参数时,重载方法的行为一致.

42.慎用可变参数

错误用例

将以

数组当做final 参数

的现有方法,改造成

可变参数

来替代

List<String> list = Arrays.asList("to","too","two");

这么做会引发一些问题:

历史问题:

比如之前打印数组,最好使用下面的代码:

System.out.println(Arrays.asList(mArray));//这样是为了避免 调用到 Object.toString

这种做法只有在

引用类型

上才有效 ,比如,如下示例:

int[] digits = {1,2,3,5,4,6};
System.out.println(Arrays.asList(digits));

这里会产生错误, 因为

asList

的方法声明为

asList(Object[]);

可变参数

当可变参数引入后,就出现了最开始的用法了,这时候,如下用法

int[] digits = {1,2,3,5,4,6};
System.out.println(Arrays.asList(digits));// digits 当做可变参数中的一个参数

这时候,会打印出

[[I@3e25a5

类似无意义的结果,

最新可用方法,如果使用下面的方法,则没有问题

int[] digits = {1,2,3,5,4,6};
System.out.println(Arrays.toString(digits));

总结

可变参数的每次调用都会 进行一次数组的分配和初始化.避免性能损耗,可以使用如下方式,在大多数时候 , 调用

非可变参数

方法

public void foo(){}
public void foo(int a){}
public void foo(int a,int b){}
public void foo(int a,int b,int ... args){}

EnumSet 就是采用这种机制.

不必改造具有final数组参数的每个方法.只有确定

它是在数量不定的值上执行

才使用可变参数.

43.返回零长度的数组或者集合,而不是null

返回null的示例

比如,如下示例:

private final List<Cheese> mCheeses = ...;
public Cheese[] getCheeses(){
if (mCheeses.size() ==0)
return null;
}

针对上面的代码,客户端的处理

Cheese[] mCheeses = getCheeses();
if(mCheeses != null &&Arrays.asList(mCheeses).contains(Cheese.STILTON)){
System.out.println("Jolly goog,just the thing");
}

返回

null

,而不是集合的形式,几乎每次客户端都要判空处理

客户端如果忘记处理,则会引起严重的问题

返回集合

public static final Cheese[] EMPTY_CHEESE_ARRAY = new Cheese[0];
private final List<Cheese> mCheeses = ...;
public Cheese[] getCheeses(){
// 如果集合是 空的 ,将返回零长度数组,如果达到足够容纳这个集合,就返回这个数组
return mCheeses.toArray(EMPTY_CHEESE_ARRAY);
}

不仅服务端代码简单可扩展了,也方便了客户端

小结

简而言之, 返回类型 为数组或集合的方法

没理由 返回 null

,而不是返回一个

零长度的数组或者集合

.

44.为所有导出的API元素编写文档注释

原则

为了 正确的编写 API 文档,必须在每个被导出的类,接口,构造器,方法和域声明之前增加一个文档注释

方法的文档注释应该简洁的描述出,他和客户端之间的约定

插入代码标签,可以使用

<pre>{@code }</pre>

为了让

<

,

>

,等字符出现在文档中,可以使用

{@literal}

标签

为了避免混淆,同一个类或者接口中的两个成员或者构造器,不应该使用同样的概要或者描述.

为泛型或者方法编写文档时,确保说明所有的类型参数

为注解类型编写文档时,确保说明所有成员