BuilderPattern中的逻辑

Question

最近我遇到了一个引起我兴趣的建设者模式。

所以，我有一个EntityBuilder来构建Entity，但它并没有返回实体。这是方法签名：

public void build();

相反，在build()方法中，它将创建的新对象Entity传递给CacheImplementation实例以存储它。 注意：CacheImpl是在构建器的构造函数中注入的。

public void build(){
    //create new entity
    cacheImplementation.add(entity);
}

这听起来像是最佳做法吗？

稍后编辑0

public interface EntityBuilder {

    void setProperty0(PropertyObject propertyObject0);
    void setProperty1(PropertyObject propertyObject1);
    void setProperty2(PropertyObject propertyObject2);
    //...

    void build();
}

public class EntityBuilderImpl implements EntityBuilder {

    PropertyObject propertyObject0;
    PropertyObject propertyObject1;
    PropertyObject propertyObject2;
    //...

    // setters for all properties
    @Override
    public void build(){
        //create new entity
        cacheImplementation.add(entity);
    }
}

构建器按以下方式使用：

public class EntityProcessor{
  private EntityBuilderFactory entityBuilderFactory;//initialized in constructor

  void process(EntityDetails entityDetails){
       EntityBuilder entityBuilder = this.entityBuilderFactory.getNewEntitytBuilder();
       //..
       // entityBuilder.set all properties from entityDetails
       entityBuilder.build();
  }
}

注意：cacheImpl实例只将实体存储在List<>中，每隔N秒访问一次。

Answer 1

  

这听起来像是最佳做法吗？

传统的构建器模式不会将创建的对象存储在任何位置，而只是返回它。

我可以想象一个变体，其中构建器还具有实例控制的作用，以避免创建重复的对象，以及管理不可变对象的存储。

不返回实例的决定可能是明确该方法有副作用。如果该方法返回了该对象，则可能会误导它认为它是一个没有副作用的传统构建器，而在此情况并非如此。

在任何情况下，所有这些只是推测，因为我们还没有看到使用它的其余代码以及它的实现和使用方式。我们没有足够的背景来真正判断。 发明新模式没有任何问题，但可以做得好或坏。

Answer 2

我在JCodeModel课程中看到过类似的void build()方法。正如您所看到的，由于IOException：

，它会抛出resources it manages

public void build(File destDir,
                  PrintStream status)
           throws IOException

您基本上要求它为您执行操作，如果没有错误 - 您可以继续工作流程。

Answer 3

通常，构建器以下列方式使用： 某些类将使用构建器来创建类。简单

现在你有额外的复杂性 - 缓存。您可以将缓存放在Builder内部或处理器内部更高级别。

在构建器中放置缓存管理有什么意义：

• Builder不再承担单一责任。
• 乍看之下，你的工作方式并不奏效
• 如果没有将对象放入缓存中，则无法创建对象

如果将缓存管理放在单独的类中，则不会发生这些问题。

我会说这不是一个糟糕的解决方案，但肯定会降低代码的可维护性。