disadvantages of builder design pattern

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 mentioned the good and bad consequences of design patterns. But they haven't mentioned any bad consequence for builder design pattern.

Solution 1

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.

Solution 2

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.

Solution 3

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...

Solution 4

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.

Solution 5

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

View more solutions

Comments

[Ivan]

This question can't be answered without context. What problem are you trying to solve with the builder pattern? The builder pattern is a way to solve certain problems in statically typed languages, but can't be used to solve other problems in the same language, making it impossible to say if its "good" or "bad".

[Robben_Ford_Fan_boy]

It depends. If your class looks like it will have constrctors with more than a handful of parameters then the builder design pattern will be a good choice. However, if the only purpose of the class your designing is to print the string "Trousers" to the screen then its probably overkill...

[Angel O'Sphere]

-1, all 3 points are wrong. A builder pattern has absolutely nothing to do with DB mapping, being mutable or not, the third point of you indicate that you don't actually know what the purpose of the builder pattern is.

[Espen]

@Angel: Mapping framework usually uses set methods and constructors to set an objects different values. Have you ever used a generic mapping framework before? Your last two arguments are rather weak.

[Angel O'Sphere]

And what does "setMethods" or "constructors" as used in mapping frameworks to do with the builder pattern? Correct: nothing I strongly suggest to read the GOF definition of the builder pattern.

[Espen]

@Angel: I said it is not a good match.. That means you should select either the builder pattern or a mapping framework for a class. Can you please explain better what is wrong with the last two points?

[Angel O'Sphere]

Well, a mapping framework is for mapping memory to DB and back. A Builder is for constructing complex object graphs in memory. Both are topics which have nothing todo with each other. A complex graph constructed via a builder is still easy mapped to a DB and back with hibernate etc. How does a builder work? Ofc it uses the exact same ctor hibernate would use. And it uses the exact same setter hibernate would use to inject one object into another one. Finally: a builder is a simplification for constructing objects via an algorithm. A mapper is for persistance. There is no relation at all.

[Angel O'Sphere]

In an answer above someone linked this: stackoverflow.com/questions/1673841/… Unfortunately ALL builders there are not examples of the "Design Pattern Builder", perhaps that adds to the confusion here.

[prashant]

+1 to make up for @AngelO'Sphere's -1. The Builder pattern Espen's talking about is Josh Bloch's from Effective Java 2nd Ed. (see this answer). In that, the constructor the Builder uses is private; one goal of the pattern is to encourage immutability by allowing all fields to be final (rather than initializing via setters); and for objects with a small number of heterogeneous fields it is indeed overkill. (Though it might still be worth considering a static factory method and a private constructor, which would ease adding a Builder later.)

[Lawrence]

Old thread, however I see no reason why mandatory or optional should be a parameter to decide whether you should use this or that method to get data set. Back in the days when people were writing plain C/C++ code, we didn't have all this. I guess we knew what we were doing. Naturally things advance but for me, the builder pattern clutters up your classes, is more work, renders code more difficult to read and does increase maintenance. I've seen it, it starts with a Builder, next there is a Constructor and setters. All 3 of them. And all because someone wrote a book called Effective Java.

[Lawrence]

Just one comment, you don't know the future so you should not write code based on assumptions (unless when a next sprint clearly tells differently). Write code as if your specs are final. (once more, unless you know a next sprint clearly says differently). That way it will be as efficient as it gets in the end.

[Jarle Hansen]

Mandatory + optional are a feature of the builder pattern shown in effective java, so therefore it is something to consider. Also if you need immutability of course. The argument that someone, sometime did misuse it is really bad. You can use public fields if you want, its a lot less code.