java怎么定义构造器_Java 换一种方式定义你的构造器

前言

上一篇记录了用静态工厂 VS 构造器，本片继续记录书中的提到的其它的方式。

阐述

在第二节开篇，作者提出自己的见解。静态工厂和构造器有个共同的局限性，它们都不能很好的拓展到大量的可选参数。

本想使用自己在练习中的例子，但书中给的实例实在是优秀，所以下文大部分引用书中的案例。比如，用一个类表示包装食品的营养成分标签，其中有几个域是必须的：每份的含量、每罐的含量以及每份的卡路里。还有几个可选域：总脂肪量、饱和脂肪量、转化脂肪、胆固醇、钠等等。大多数产品在几个可选域中都会有非零的值。

重叠构造器

对于选用哪种方式来创建，按照我们常规的方式一般就会采用 重叠构造器 模式，这种模式中，提供的第一个构造器只需包含必要的参数，第二个构造器有一个可选参数，第二个构造器有两个可选参数，以此类推，最后一个构造器包含所有的可选参数。以下是一个只显示四个可选域的实例：

public class NutritionFacts {

private final int servingSize; // (mL) required

private final int servings; // (per container) required

private final int calories; // optional

private final int fat; // (g) optional

private final int sodium; // (mg) optional

private final int carbohydrate; // (g) optional

​

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;

}

}

public static void main(String[] args) {

NutritionFacts cocaCola = new NutritionFacts(240, 8, 100, 0, 35, 27);

}

public class NutritionFacts {

// Parameters initialized to default values (if any)

private int servingSize = -1;

private int servings = -1;

private int calories = 0;

private int fat = 0;

private int sodium = 0;

private int carbohydrate = 0;

​

public NutritionFacts() {}

// set function

public void setServingSize(int val) { servingSize = val; }

public void setServings(int val) { servings = val; }

public void setCalories(int val) { calories = val; }

public void setFat(int val) { fat = val; }

public void setSodium(int val) { sodium = val; }

public void setCarbohydrate(int val) { carbohydrate = val; }

}

public static void main(String[] args) {

NutritionFacts cocaCola = new NutritionFacts();

cocaCola.setServingSize(240);

cocaCola.setServings(8);

cocaCola.setCalories(100);

cocaCola.setSodium(35);

cocaCola.setCarbohydrate(27);

}

public class NutritionFacts {

private final int servingSize;

private final int servings;

private final int calories;

private final int fat;

private final int sodium;

private final int carbohydrate;

​

public static class Builder {

// Required parameters

private final int servingSize;

private final int servings;

​

// Optional parameters - initialized to default values

private int calories = 0;

private int fat = 0;

private int carbohydrate = 0;

private int sodium = 0;

​

public Builder(int servingSize, int servings) {

this.servingSize = servingSize;

this.servings = servings;

}

​

public Builder calories(int val) {

calories = val;

return this;

}

​

public Builder fat(int val) {

fat = val;

return this;

}

​

public Builder carbohydrate(int val) {

carbohydrate = val;

return this;

}

​

public Builder sodium(int val) {

sodium = val;

return this;

}

​

public NutritionFacts build() {

return new NutritionFacts(this);

}

}

​

private NutritionFacts(Builder builder) {

servingSize = builder.servingSize;

servings = builder.servings;

calories = builder.calories;

fat = builder.fat;

sodium = builder.sodium;

carbohydrate = builder.carbohydrate;

}

}

public static void main(String[] args) {

NutritionFacts cocaCola = new NutritionFacts.Builder(240, 8)

.calories(100).sodium(35).carbohydrate(27).build();

}虽然本书中的规则不会百分之百地适用于任何时刻和任何场合，但是，它们确实体现了绝大多数情况下的最佳编程实践。你不应该盲目的遵循这些规则，但偶尔有了充分的理由之后，可以去打破这些规则。同大多数学科一样，学习编程艺术首先要学会基本的规则，然后才能知道什么时候去打破它。

非常喜欢的书中摘录：

总结

这样的客户端代码很容易编写，更为重要的是易于阅读，Builder 模式模拟了明确命名的可选参数。

注意 NutritionFacts 是不可变的，所有的默认参数都单独放在一个地方，Buildr 的设值方法返回 Builder 本身，以便把调用链接起来，得到一个流式的 API。下面是调用示例：

👇示例：客户端调用无参的 Build 方法来生成是不可变的对象。

然后客户端在 Builder 对象上调用类似于 Setter 的方法来设置必要参数。

它不直接生成想要的对象，而是让客户端利用有必要的参数调用构造器，得到一个 Builder 对象。它既能保证像重叠构造器模式那样的安全性，也能保证像 JavaBean 模式那么好的可读性

建造者模式

针对这种情况，书中给出了第三种替代方式。类在构造过程中被分到了几个调用中，在构造过程中 JavaBean 可能处于不一致的状态

类无法仅仅通过检验构造器参数的有效性来保证一致。

JavaBean 模式使得把类做成不可变的可能性不复存在(后边单独更新)，需要付出额外的努力确保它的线程安全

美中不足的是，JavaBean 模式自身有一些缺点：

这种模式弥补了重叠构造器的不足，创建实例很容易，这样的代码可读性也非常高：

这种模式下，先调用一个无参构造器来创建对象，然后通过调用 set 方法来设置每个必要的参数和可选参数，例如：

JavaBean 模式

这种情况下，还有第二种替代方式。

如果我们想知道具体的值是什么意思，必须仔细地去读参数的注释。如果是一长串类型相同的参数必然会导致一些微妙的错误，如果不小心颠倒了其中两个参数的顺序，编译器并不会报错，但是最终的结果可能会出现错误的行为。

简而言之，重叠构造器模式可行，但是当有许多参数的时候，客户端的代码会很难编写，并且难以阅读。

其中的某个参数可能是我们不想设置的，但是不得不为它们传递值。这个例子中，我们给 fat 传递了一个值为 0。如果仅仅是 6 个参数，还在我们的可控范围，问题是随着功能和参数的增加，很快就会失去控制。

一般情况下，实例化对象的时候会变成以下这个样子：