Logic inside BuilderPattern

Question

Recently, I came across a build pattern that intrigued me.

So, I have an EntityBuilder that builds an Entity but does not return an object. Here is the method signature:

 public void build(); 

Instead, inside the build() method, it delivers the new object created by Entity to the CacheImplementation instance to save it. Note: CacheImpl is injected into the constructor constructor.

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

Does that sound like best practice?

Edit 0 later

 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); } } 

The builder is used as follows:

 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(); } } 

Note: the cacheImpl instance simply stores the objects in List<> , which access every N seconds.

Answer 1

Does that sound like best practice?

The traditional builder pattern does not save the created object anywhere, it simply returns it.

I can imagine a variation in which the builder also plays the role of instance control to avoid creating duplicate objects and managing the storage of immutable objects.

The decision not to return an instance may be to make it clear that the method has a side effect. If a method returns an object, it may be misleading to think that it is a traditional builder without side effects if it is not.

In any case, all this is just an assumption, since we have not seen the rest of the code where it is used, and the way it is implemented and used. We don’t have enough context to really judge. There is nothing wrong with inventing new templates, but this can be done good or bad.

Answer 2

I saw a similar void build() method in the JCodeModel class. As you can see, it throws an IOException because of the resources it manages :

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

Basically you ask him to perform the operation for you, and if there is no error, you can continue the workflow.

Answer 3

In general, the builder is used as follows: Some classes will use the builder to create the class. Plain

---

Now you have the added complexity of caching. You can put caching inside the Builder or one level higher inside the Processor.

What are the consequences of enabling cache control inside the builder:

• Builder no longer has any responsibility.
• This does not work as you would expect at first glance.
• You cannot create an object without putting it in the cache

These problems will not occur if you add cache management to a separate class.

---

I would say that this is not a terrible decision, but it will certainly reduce the maintainability of your code.