Core Java

Design Patterns: Builder

Sometimes there is a need to create a complex object in application. The one solution for this is a Factory pattern, the another one is a Builder design pattern. In some situation you even can combine these two patterns. But in this article I want to examine the Builder design pattern. The first thing which I need to say that it is a creational In what situations you should use the Builder design pattern? Definitely when creation of the object requires a plenty of another independent objects. When you want to hide creation process from the user. When you can have different representation of the object in the end of the construction process.

Let’s proceed with a code example. UML scheme of the pattern:


As I mentioned the Builder pattern is the creational pattern. This circumstance implies creation of some object (product) in the end of the process. The product is created with the help of a concrete builder, in its turn the builder has some parent builder class or interface. The final point of the pattern is a director class, it is responsible for creation of the concrete builder for the appropriate product.

The example will be based on famous and epic computer game – StarCraft. A role of the product will play a Zealot it is a simple battle Protoss unit. The director’s role will play a Gateway. And the concrete builder is a ZealotBuilder. All code I will provide below:

Abstract class for the game units:

public abstract class Unit {

	protected int hitPoints;
	protected int armor;
	protected int damage;

	public int getHitPoints() {
		return hitPoints;

	public void setHitPoints(int hitPoints) {
		this.hitPoints = hitPoints;

	public int getArmor() {
		return armor;

	public void setArmor(int armor) {
		this.armor = armor;

	public int getDamage() {
		return damage;

	public void setDamage(int damage) {
		this.damage = damage;


Class of the Zealot (product):

public class Zealot extends Unit {

	public String toString() {
		return "Zealot is ready!"+
				"\nHitPoints: "+getHitPoints()+
				"\nArmor: "+getArmor()+
				"\nDamage: "+getDamage();


Interface of the builder:

public interface UnitBuilder {

	public void buildHitPoints();
	public void buildArmor();
	public void buildDamage();
	public Unit getUnit();


Implementation of the builder interface:

public class ZealotBuilder implements UnitBuilder {

	private Unit unit;

	public ZealotBuilder() {
		unit = new Zealot();

	public void buildHitPoints() {

	public void buildArmor() {

	public void buildDamage() {

	public Unit getUnit() {
		return unit;


The Gateway (Director) class:

public class Gateway {

	public Unit constructUnit(UnitBuilder builder) {
		return builder.getUnit();


And now let’s see how it works all together:

	public static void main(String[] args) {

		UnitBuilder builder = new ZealotBuilder();
		Gateway director = new Gateway();
		Unit product = director.constructUnit(builder);


The result of the last code snippet is:

Zealot is ready!
HitPoints: 100
Armor: 50
Damage: 8

So as you can see the Builder design pattern is really helpful in situation when you need to create complex objects. The example in the tutorial wasn’t really hard, but now you can imagine in what situation you can apply this approach. More articles about the design patterns you can find here.

Reference: Design Patterns: Builder from our JCG partner Alexey Zvolinskiy at the Fruzenshtein’s notes blog.

Alexey Zvolinskiy

Alexey is a test developer with solid experience in automation of web-applications using Java, TestNG and Selenium. He is so much into QA that even after work he provides training courses for junior QA engineers.
Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Inline Feedbacks
View all comments
Back to top button