创建和销毁对象——遇到多个构造器参数时要考虑使用构建器

左手的ㄟ右手 2024-03-26 10:54 50阅读 0赞

静态工厂和构造器有个共同的局限性：它们都不能很好地扩展到大量的可选参数。比如用一个类表示包装食品外面显示的营养成分标签。这些标签中有几个域是必需的：每份的含量、每罐的含量以及每份的卡路里。还有超过20个的可选域：总脂肪量、饱和脂肪量、转化脂肪、胆固醇、钠等等。大多数产品在某几个可选域中都会有非零的值。

对于这样的类，应该用哪种构造器或者静态工厂来编写呢？程序员一向习惯采用重叠构造器模式，在这种模式下，提供的第一个构造器只有必要的参数，第二个构造器有一个可选参数，第三个构造器有两个可选参数，以此类推，最后一个构造器包含所有可选的参数。下面有个示例，为了简单起见，它只显示四个可选域：

**final修饰的变量表示赋值之后不能再进行更改，系统赋默认值也算赋值，因此系统也不会赋默认值**

当你想要创建实例的时候，就利用参数列表最短的构造器，该列表中包含了要设置的所有参数：

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

这个构造器调用通常需要许多你本不想设置的参数，但还是不得不为它们传递值。在这个例子中，我们给fat 传递了一个值为0 。 如果“仅仅”是这6个参数，看起来还不算太糟糕，问题是随着参数数目的增加，它很快就失去了控制。

简而言之，重叠构造器模式可行，但是当有很多参数的时候，客户端代码会很难编写，并且仍然很难阅读。如果读者想知道那些值是什么意思，必须很仔细地数着这些参数来探个究竟。一长串类型相同的参数会导致一些微妙的错误。如果客户端不小心颠倒了其中两个参数的顺序，编译器也不会出错，但是程序在运行时会出现错误的行为

遇到许多可选的构造器参数的时候，**还有第二种代替办法，即JavaBeans模式**，在这种模式下，取消掉final修饰符，先调用一个无参构造器来创建对象，然后再调用setter 方法来设置每个必要的参数，以及每个相关的可选参数

/**
     * 营养成分
     */
    public class NutritionFacts {
    
        private  int servingSize; //  每份含量             required
        private  int servings; //    每罐含量     required
    
        private  int calories;// 卡路里/罐      optional
        private  int fat;//   脂肪/罐              optional
        private  int sodium; //   钠/罐         optional
        private  int carbohydrate; // 碳水/罐     optional
    
        public int getServingSize() {
            return servingSize;
        }
    
        public void setServingSize(int servingSize) {
            this.servingSize = servingSize;
        }
    
        public int getServings() {
            return servings;
        }
    
        public void setServings(int servings) {
            this.servings = servings;
        }
    
        public int getCalories() {
            return calories;
        }
    
        public void setCalories(int calories) {
            this.calories = calories;
        }
    
        public int getFat() {
            return fat;
        }
    
        public void setFat(int fat) {
            this.fat = fat;
        }
    
        public int getSodium() {
            return sodium;
        }
    
        public void setSodium(int sodium) {
            this.sodium = sodium;
        }
    
        public int getCarbohydrate() {
            return carbohydrate;
        }
    
        public void setCarbohydrate(int carbohydrate) {
            this.carbohydrate = carbohydrate;
        }
    }

这种模式弥补了重叠构造器模式的不足。说得明白一点，就是创建实例很容易，这样产生的代码读起来也很容易：

NutritionFacts cocaCola = new NutritionFacts();
    cocaCola.setServingSize(240);
    cocaCola.setServings(8);
    cocaCola.setCalories(100);
    cocaCola.setSodium(35);
    cocaCola.setCarbohydrate(27);

遗憾的是，JavaBeans 模式自身有着很严重的缺点。因为构造过程被分到了几个调用中， 在构造过程中，JavaBeans 可能处于不一致的状态。类无法仅仅通过检验构造器参数的有效性来保证一致性。试图使用处于不一致状态的对象将会导致失败，这种失败与包含错误的代码大相径庭，因此调试起来十分困难。与此相关的另一点不足在于，JavaBeans 模式使得把类做成不可变的可能性不复存在，这就需要程序员付出额外的努力来确保它的线程安全。

幸运的是，还有第三种替代方法，它既能保证像重叠构造器模式那样的安全性，也能保证像JavaBeans 那么好的可读性。这就是建造者（Builder）模式的一种形式，它不直接生成想要的对象，而是让客户端利用所有必要的参数调用构造器（或者静态工厂），得到一个builder 对象。然后客户端在builder 对象上调用类似于setter 的方法，来设置每个相关的可选参数。最后，客户端调用无参的build 方法来生成通常是不可变的对象。这个builder 通常是它构建的类的静态成员类，下面就是它的示例：

/**
     * 营养成分
     */
    public class NutritionFacts {
        private final int servingSize; //  每份含量             required
        private final int servings; //    每罐含量     required
    
        private final int calories;// 卡路里/罐      optional
        private final int fat;//   脂肪/罐              optional
        private final int sodium; //   钠/罐         optional
        private final int carbohydrate; // 碳水/罐     optional
    
        private NutritionFacts(Builder builder) {
            servingSize = builder.servingSize;
            servings = builder.servings;
            calories = builder.calories;
            fat = builder.fat;
            sodium= builder.sodium;
            carbohydrate = builder.carbohydrate;
        } 
        
        public static class Builder{
            private int servingSize; // (ml) 每份含量             required
            private int servings; // (per container) 每罐含量     required
    
            private int calories;// (per serving) 卡路里/每罐      optional
            private int fat;// (g/serving)脂肪  g/罐              optional
            private int sodium; // (mg/serving) 钠  mg/罐         optional
            private int carbohydrate; //(g/serving) 碳水 g/罐     optional
    
            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 sodium(int val){
                sodium = val;
                return this;
            }
            public Builder carbohydrate(int val){
                carbohydrate = val;
                return this;
            }
    
            public NutritionFacts build(){
                return new NutritionFacts(this);
            }
        }
    }

注意 NutritionFacts 是不可变的，所有的默认参数值都单独放在一个地方。builder的设置方法返回自身，以便把调用链接起来，得到一个流式API。下面就是其客户端代码：

NutritionFacts cocaCola = new NutritionFacts
                                    .Builder(240,8)
                                    .calories(100)
                                    .sodium(35)
                                    .carbohydrate(27)
                                    .build();

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

为了简洁起见，示例中省略了有效性检查。要想尽快侦测到无效的参数，可以在builder 的构造器和方法中检查参数的有效性。查看不可变量，包括build方法调用的构造器中的多个参数。为了确保这些不变量免受攻击，从builder 复制完参数之后，要检查对象域（详见第50条）。如果检查失败就抛出 IllegalArgumentException，其中的详细信息会说明哪些参数是无效的。

与构造器相比，builder 的微弱优势在于，它可以有多个可变（varargs）参数。因为builder 是利用单独的方法来设置每一个参数。

Builder 模式的确也有它自身的不足。为了创建对象，必须先创建它的构建器。虽然创建这个构建器的开销在实践中可能不那么明显，但是在某些十分注重性能的情况下，可能就成问题了。Builder 模式还比重叠构造器模式更加冗长，因此它只在有很多参数的时候才使用，比如4个或更多。但是记住，将来你可能需要添加参数。如果一开始就使用构造器或静态工厂，等到类需要多个参数时才添加构造器，就会无法控制，那些过时的构造器或者静态工厂显得十分不协调。因此，通常最好一开始就使用构建器（Builder）。

简而言之，如果类的构造器或者静态工厂中具有多个参数，设计这种类时，Builder模式就是一种不错的选择，特别是当大多数参数都是可选或者类型相同的时候。与使用重叠构造器模式相比，使用Builder 模式的客户端将更易于阅读和编写，构建器也比JavaBeans 更加安全

--------------------

如果是内部调用较多，确定没有安全问题，JavaBean模式和builder 已经非常接近了，并且，可以使用链式调用的方式，让JavaBean 的调用显得更简洁，更像builder

/**
     * 营养成分
     */
    public class NutritionFacts {
        private int servingSize; //  每份含量             required
        private int servings; //    每罐含量     required
    
        private int calories;// 卡路里/罐      optional
        private int fat;//   脂肪/罐              optional
        private int sodium; //   钠/罐         optional
        private int carbohydrate; // 碳水/罐     optional
    
    
        public NutritionFacts setServingSize(int servingSize) {
            this.servingSize = servingSize;
            return this;
        }
    
        public NutritionFacts setServings(int servings) {
            this.servings = servings;
            return this;
        }
    
        public NutritionFacts setCalories(int calories) {
            this.calories = calories;
            return this;
        }
    
        public NutritionFacts setFat(int fat) {
            this.fat = fat;
            return this;
        }
    
        public NutritionFacts setSodium(int sodium) {
            this.sodium = sodium;
            return this;
        }
    
        public NutritionFacts setCarbohydrate(int carbohydrate) {
            this.carbohydrate = carbohydrate;
            return this;
        }
    
        public static void main(String[] args) {
            NutritionFacts cocaCola = new NutritionFacts()
                    .setServingSize(240)
                    .setServings(8)
                    .setCalories(100)
                    .setSodium(35)
                    .setCarbohydrate(27);
        } 
    }

当然，现在很多公司和团队已经开始积极使用Lombok 来简化bean 对象。可以如下

/**
     * 营养成分
     */
    @Getter
    @Setter
    @Accessors(chain = true)
    public class NutritionFacts {
        private int servingSize; //  每份含量             required
        private int servings; //    每罐含量     required
    
        private int calories;// 卡路里/罐      optional
        private int fat;//   脂肪/罐              optional
        private int sodium; //   钠/罐         optional
        private int carbohydrate; // 碳水/罐     optional
    
        public static void main(String[] args) {
            NutritionFacts cocaCola = new NutritionFacts()
                    .setServingSize(240)
                    .setServings(8)
                    .setCalories(100)
                    .setSodium(35)
                    .setCarbohydrate(27);
        }
    }