0% found this document useful (0 votes)
9 views13 pages

Section 6 - Part 1 (Builder Design Pattern)

The document discusses the Builder Design Pattern, a creational design pattern that facilitates the step-by-step construction of complex objects, such as a Pizza. It highlights problems with traditional object construction, including long constructors with too many parameters, difficulty in handling optional fields, and lack of flexibility for different object representations. The solution involves extracting construction logic to separate builder classes, improving code readability and maintainability.

Uploaded by

israahussein737
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
9 views13 pages

Section 6 - Part 1 (Builder Design Pattern)

The document discusses the Builder Design Pattern, a creational design pattern that facilitates the step-by-step construction of complex objects, such as a Pizza. It highlights problems with traditional object construction, including long constructors with too many parameters, difficulty in handling optional fields, and lack of flexibility for different object representations. The solution involves extracting construction logic to separate builder classes, improving code readability and maintainability.

Uploaded by

israahussein737
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 13

Selected Labs in Software

Engineering
Section (6) Part 1– Builder Design Pattern

Eng. Essam Ayman


Teaching Assistant
Builder Design Pattern
Builder is a creational design pattern that lets you construct complex objects step by
step. The pattern allows you to produce different types and representations of an
object using the same construction code.
Problem
• Imagine a complex object that requires laborious, step-by-step initialization of many
fields and nested objects. Such initialization code is usually buried inside a monstrous
constructor with lots of parameters. Or even worse: scattered all over the client code.
• You might make the program too complex by creating a subclass for every possible
configuration of an object.
• Imagine a Pizza object. To create a pizza, we need fields such as:

1. Id
2. Name
3. Size
4. Crust
5. hasCheese
6. hasToopings
7. isSpicy
8. Price
9. dileveryTime
What are the problems with previous class?

• Problem 1: Long Constructor with Too Many Parameters

• The constructor requires all fields to be passed, making it long and hard to read.

Pizza pizza = new Pizza(1, "Deluxe Feast", 14, "Stuffed Crust", true, true, true, 25.99, 30);

• This can lead to mistakes, such as passing parameters in the wrong order.
What are the problems with previous class?

• Problem 2: Difficult to Create Objects with Optional Fields.

• If some fields (e.g., hasExtraToppings or isSpicy) are optional, you must still include
them in the constructor.

• You might have to pass default values like false, null, or 0 for fields you don’t want,
which clutters the code.

Pizza pizza = new Pizza(1, null, 14, null, true, true, true, 25.99, 0);

• This is called ugly calling to the constructor


What are the problems with previous class?
• Problem 3: No Flexibility in Handling Different Representations of the Object

• The class lacks flexibility in creating different representations of the Pizza object. For instance,
you may want to create:

• Simple Pizzas: Basic pizzas with only size, crust, and name.
• Deluxe Pizzas: Pizzas with extra toppings, cheese, and spices.
• Custom Pizzas: Pizzas with all fields, including delivery time and price.

• Handling these different representations becomes a challenge with the current design.
• You can attempt to solve this problem by creating multiple overloaded constructors, each
handling a specific variation of the Pizza object

public Pizza(String pizzaName, int size, String crust);


public Pizza(String pizzaName, int size, String crust, boolean hasCheese);
public Pizza(String pizzaName, int size, String crust, boolean hasCheese, double price);

• This increases code complexity and makes maintenance harder


What are the problems with previous class?
• Problem 3: No Flexibility in Handling Different Representations of the Object
• Another inefficient solution is to create subclasses for each type of pizza. For example:
Solution (builder design pattern)
• The Builder pattern suggests that you extract the object construction code out of its
own class and move it to separate objects called builders.

• Steps:
• 1. Define the Product Class (Pizza)
• 2. Create the Builder Class
• 3. Add a Director Class (Optional)
• 4. Client Code
Solution (builder design pattern)
• 1. Define the Product Class (Pizza)
Solution (builder design pattern)
• 2. Create the Builder Class
Solution (builder design pattern)
• 3. Add a Director Class (Optional)
Solution (builder design pattern)
• 4. Client Code

You might also like