disadvantages of builder design pattern [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 3 years ago.

Improve this question

What would be the disadvantages of using the builder design pattern. Are there any??

edit - I want to know whether there is any bad consequence of using builder design pattern? As in the GOF book, they have menti开发者_StackOverflow中文版oned the good and bad consequences of design patterns. But they haven't mentioned any bad consequence for builder design pattern.

---

It does create more code (and could introduce more complexity) in the DTO than if you had for example contructor arguments and/or setters/getters.

In my opinion this is not a big deal, in most cases there is not a lot of extra code. The builder pattern will be more than worth it if you have an object that has some mandatory and some optional parameters.

---

A pattern is only disadvantageous when the pattern is been abused/misused. I.e. the pattern didn't solve/suit the actual technical/functional problem at all. You should then to look for another pattern to solve the particular problem.

This doesn't specifically apply to the builder pattern, but to design patterns in general.

---

Update: if you'd be interested to learn about the various design patters (specifically the ones mentioned in the GoF Design Patterns book) and the real world examples in Java API, then you may find this answer: Examples of GoF Design Patterns in Java's core libraries useful. It contains links to Wikipedia articles explaining the patterns in detail.

---

I second Jarle's post.

Else, when it comes to disadvantages:

• The builder pattern isn't a good match if you have to map the DTO with for example Hibernate or JAXB.
• If you for some reasons want a mutable object.
• For small DTOs with two or three fields, it's just overhead and you should rather use a constructor or two. Unless you know/believe the DTO will contain more fields in the future.

---

Builder pattern, when used with the idea in mind to overcome the lack of optional parameters in Java, you lose the static analysis provided by the compiler (and all the nice refactoring features provided by your IDE). This means that you'll detect that some mandatory parameters are missing only at runtime, instead of having your IDE telling you immediately that something is wrong...

---

comparing to telescope constructors

• loss of static analysis
• for missing mandatory parameters an exception needs to be thrown and catched somethere
• if you use boxed types in builders to represent primitive values which are not set yet, then there is a lot of auto-boxing/unboxing going on - which allows for NullPointerExceptions which are hard to spot. No such problem in telescope constructors - you can just pass primitive values.
• a lot more code