Builder Pattern 的替代实现。这有什么问题吗？

Question

我看到的大多数Builder模式的实现都是这样的：

https://github.com/Design-pattrns/Builder-Pattern/blob/master/src/Computer.java

基本上，嵌套构建器 class 需要镜像我们构建对象所需的 class 的所有属性，然后提供设置所述属性的方法和一个额外的 build() 方法在生成器内部 class.

当我尝试自己实现构建器时，我想到了这个（我在构建器中使用了一个 Person 对象的实例，而不是复制 Person 的所有属性 class）

public class Person {

 private String firstName;
 private String lastName;

 public static class PersonBuilder{
     private Person person = new Person();

     public PersonBuilder firstName(String firstName){
         person.firstName = firstName;
         return this;
     }

     public PersonBuilder lastName(String lastName){
         person.lastName = lastName;
         return this;
     }

     public Person build(){
         return person;
     }
 }
}

好处：

1).不需要重复我们要实例化的class的属性

2). build 方法被简化了，只需要 return person 对象。

3). Person class 不需要将 Builder 对象作为参数的构造函数

4).更容易“更新”。如果给 person class 添加新的属性，我们只需要如果需要，要做的是在构建器 class 中添加 set 方法。无需创建另一个属性。

缺点：

1). person 对象是否已初始化？

那么这个实现有什么问题吗？

Answer 1

我想说上面的示例“更简单”，但它具有构建器提供的 none 优势，并且最好只在需要对象的地方使用新关键字并将属性添加到构造函数。我说相对于builder的缺点如下：

它只能创建一个实例
一旦构建器“完成”，它就可以继续与对象交互，因为它仍然持有对它的引用。
它与它正在“构建”的产品紧密结合。
这个人 class 必须公开很多属性作为构建器的可变属性，您可能希望在代码的其他地方不可变。

它实际上更像是一个配置器，我不建议使用这种模式但是您可以将要配置的对象传递到构造函数中。在这种情况下，我会创建两个接口

IConfigurablePerson 包括设置器
包括 getter 的 IPerson

将配置器 IConfigurablePerson 提供给它的构造函数，这样它就可以访问 setter，然后将仅具有 getter 的其他 classes IPerson 提供给它。这提供的优势是它可以与 IConfigurablePerson 的多个实现一起工作，而无需知道 class 它与（解耦）一起工作。

Builder Pattern 的替代实现。这有什么问题吗？

Alternate implementation of Builder Pattern. Anything wrong with this?

oop

design-patterns

builder

builder-pattern