转载请标注:
披萨大叔的博客 http://blog.csdn.net/qq_27258799/article/details/51833504
如果您觉得这篇文章对您有帮助,请点下文章最下面的赞~
最近在读Joshua Bloch的《Effective Java》,这里做下笔记。
一般我们在写类的构造器时,如果遇到大量参数,甚至以后可能会扩展更多参数时,要用哪种构造器呢?
重叠构造器模式
这也是楼主第一反应,提供一个只有必要参数的构造器,第二个构造器有一个可选参数,一次类推,最后一个构造器包含所有参数。
如:
public class NutritionFacts{
private int servingSize; //(ml) 必填
private int servings; //(per container) 必填
private int calories;// 选填
private int fat; //(g) 选填
private int sodium; //(g) 选填
private int carbohydrate; //(g) 选填
public NutritionFacts(int servingSize, int servings) {
this(servingSize, servings, 0);
}
public NutritionFacts(int servingSize, int servings, int calories) {
this(servingSize, servings, calories, 0);
}
public NutritionFacts(int servingSize, int servings, int calories, int fat) {
this(servingSize, servings, calories, fat, 0);
}
public NutritionFacts(int servingSize,int servings, int calories, int fat, int sodium) {
this(servingSize, servings, calories, fat, sodium, 0);
}
public NutritionFacts(int servingSize, int servings, int calories, int fat, int sodium, int carbohydrate) {
this.servingSize = servingSize;
this.servings = servings;
this.calories = calories;
this.fat = fat;
this.sodium = sodium;
this.carbohydrate = carbohydrate;
}
}
这类构造器通常需要许多你本不想设置的参数,比如我只想设置fat,那我只能选择:
NutritionFacts n = NutritionFacts(int servingSize, int servings, int calories, int fat);
这也是重叠构造器的第一个缺点。
另外我们在使用这类构造时,对于这些参数,都很无感,比如这5个参数都是int类型,我要知道它们的顺序,才能正确赋值,这种基本类型参数其实还好,如果是引用类型,那就更糟糕了:
public class Event(int id, String message, Object data, Object target){
// 重叠构造1
// 重叠构造2
// 重叠构造3
……
}
假如我有如下两种构造:
Event e1 = new Event(1,"message1");
Event e2 = new Event(2,"message2", "data");
由于String是Object子类,我的e2的Object data又正好是个String,此时即使你把顺序搞错,成这样:
Event e1 = new Event(1,"message1");
Event e2 = new Event(2, "data", "message2");
也不会出错,但当你用getMessage()想取到message2时,你得到的却是data,因为你初始化时,搞错了顺序。这些逻辑上的错误并不能在编译过程中检查出来,这样的bug如果出现在一个大项目中,是很难被发现的。
所以我们发现,传统的重叠构造器有这些缺点:
1、无法自定义使用某几个参数构造对象;
2、构造的参数顺序,需要自己逻辑上检查;
JavaBeans模式
这种模式下,调用一个无参构造创建对象,然后调用setter方法设置必要的参数,这里还使用上面的类,假设每个参数都已经有个getter方法。
NutritionFacts cocaCola = new NutritionFacts();
cocaCola.setServingSize(240);
cocaCola.setServings(8);
cocaCola.setCalories(100);
cocaCola.setSodium(35);
cocaCola.setCarbohydrate(27);
这样就解决了重叠构造的两个缺点,而且可读性也不错,似乎完美,然而遗憾的是,这种模式也有自身严重的缺点。
由于构造过程是通过多行代码,被分到了几个调用中,这在多线程的环境下,可能会出现不一致的状态,这就要程序员付出额外的努力保证它的线程安全性。当对象构造完成,并且不允许在解冻之前使用时,通过手工“解冻”对象,可以弥补这些不足,但是这种方式十分笨拙。幸好我们还有今天的主角——Builder模式。
Builder模式
public class NutritionFacts {
private int servingSize; //(ml)
private int servings; //(per container)
private int calories;
private int fat; //(g)
private int sodium; //(g)
private int carbohydrate; //(g)
public static class Builder {
//必填参数
private int servingSize;
private int servings;
//选填参数
private int calories;
private int fat;
private int sodium;
private int carbohydrate;
public Builder(int servingSize, int servings) {
this.servingSize = servingSize;
this.servings = servings;
}
public Builder calories(int val) {
this.calories = val;
return this;
}
public Builder fat(int val) {
this.fat = val;
return this;
}
public Builder sodium(int val) {
this.sodium = val;
return this;
}
public Builder carbohydrate(int val) {
this.carbohydrate = val;
return this;
}
public NutritionFacts build() {
return new NutritionFacts(this);
}
}
public NutritionFacts(Builder builder) {
servingSize = builder.servingSize;
servings = builder.servings;
calories = builder.calories;
fat = builder.fat;
sodium = builder.sodium;
carbohydrate = builder.carbohydrate;
}
}
这种模式下的构造,既能保证重叠构造器那样的安全性,也能保证JavaBeans模式的良好可读性。
NutritionFacts cocaCola = new NutritionFacts.Builder(240, 8).calories(100).sodium(35).carbohydrate(27).build();
Builder模式相当灵活,可以在创建对象期间自由调整参数,当然,它也有自己的不足:
为了创建对象,必须先创建它的构造器,虽然其开销不太明显,但是在某些十分注重性能的情况下,可能就成问题了。即便如此,当我们遇到参数很多的构造时,Builder模式就是种不错的选择。