This week's book giveaway is in the JavaScript forum.
We're giving away four copies of Svelte and Sapper in Action and have Mark Volkmann on-line!
See this thread for details.
Win a copy of Svelte and Sapper in Action this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
Bartenders:
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

Do I need a POJO class if I use Builder Pattern?

 
Ranch Hand
Posts: 623
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi experts,

I just learnt that there is this Builder pattern available and I jumped into it.

However, I have changed my POJO or rather Java Bean class into Builder pattern.

I'd like to know what is the practice in the industry - as in do I need 2 classes or I can just add the builder pattern onto my existing POJO/Bean class?

Tks.
 
Marshal
Posts: 15887
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't want to read too much into what you wrote but let's just get a few things clear so we're on the same page.

Patterns are recurring solutions to similar problems. That means that they are documented rather than "formulated". In other words, somebody noticed that certain types of problems had solutions that had common characteristics, i.e., there was a pattern to how they were solved. Therefore, a design pattern like Builder is simply a formal description of the context of a problem and the solution that can be applied in that context.

When you wrote "...pattern available and I jumped into it," what exactly did you mean by that? Did you read about Builder, understand the context, and then recognize that it matched a problem you saw in your own code/design? Or (hopefully not) did you see it as something shiny and new that you could try?

..just add the builder pattern onto my existing POJO/Bean class?


This is another part that raises some doubt about how well you understood what you read about Builder. How do you imagine it would look like in code if you did that?
 
Saloon Keeper
Posts: 12269
259
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As Junilu hinted at, you don't use a pattern for its own sake. You use one because it solves a certain problem. Do you have a reason to believe you're dealing with the problem that the builder pattern solves?

A builder is used to ease the construction of an object that has a lot of (optional) dependencies. If you have a constructor that takes a lot of parameters, using that constructor can lead to code that's difficult to read:
Presumably, "van Hulst" is a last name, one of the "Stephan"s is a first name, and the meaning of Gender.MALE, "stephan@residence.example.com" and "+31 6 1234 5678" are also easy to guess. What do all the other arguments mean?

With the builder pattern, you can make the meaning of these arguments clear, without sacrificing immutability:

When you find that you need the builder pattern, you would usually create a new class for it. So "changing a POJO to a Builder" doesn't really make much sense. However, before you create a new class for a builder, you need to ask yourself whether you really need that many constructor parameters, or whether a subset of the parameters make up more granular classes:
 
    Bookmark Topic Watch Topic
  • New Topic