Builder Design Pattern

I always wonder: why the need of an extra builder? Wouldn't it be sufficient to just add the "withTomato()" etc calls to the burger itself?

Thank you for the article.

I want to add couple-o-things. I'm sorry if I sound pushy, please feel free to parry my notes and point my mistakes.

Please, oh please, do use named arguments for vague stuff (concerning methods as well):

• C#: Burger burger = new Burger(size: 14, cheese: true, tomato: true, lettuce: false, pepperoni: false);
• Java: Burger burger = new Burger(/*size*/ 14, /*cheese*/ true, /*tomato*/ true, /*lettuce*/ false, /*pepperoni*/ false);
• Kotlin: Burger burger = new Burger(size = 14, cheese = true, tomato = true, lettuce = false, pepperoni = false);

Remember about default values, which is a thing in C# and Kotlin. Sorry, Java.

Also you can place these setters inside original Burger class. Unfortunately, this way object initialization wouldn't be atomic anymore.

I just checked google, so I wouldn't suggest using double braces initialization for Java. C# initializers are OK, though, and atomic. I do not know of the same stuff for Kotlin, but its syntax for constructors is great in the first place.

Basically, the problem grows out of Java itself, because I see more elegant solutions in other languages like C# and Kotlin. At least more complex example required in order to favour builders and factories.

I'm a huge fan of returning this with java builder patterns. The fluent api you get out of it is fantastic. You can very nearly get something like a custom DSL out of just that technique alone

Aren't you duplicating the set of Boolean parameters? Why not create an instance of Burger in the BurgerBuilder constructor and return it when calling build().
Oh, I see, that way Burger won't be immutable.

Just use Lombok.

@Builder
public class Burger {
    private int size;

    private boolean cheese = false;
    private boolean tomato = false;
    private boolean lettuce = false;
    private boolean pepperoni = false;
}

that example is so OOP overkill that i don't know where to start

first:

new BurgerBuilder(14)).addPepperoni().addLettuce().addTomato().build()

instead of

new Burger(14, false, true, true, true)

1 constructor VS 1 constructor + 4 methods call, what's the gain ?

second:
you got 2 objects creations instead of 1
what's the gain ?

third: immutability

public class Burger {
    private int size;

    private boolean cheese = false;
    private boolean pepperoni = false;
    private boolean lettuce = false;
    private boolean tomato = false;

    public Burger(BurgerBuilder builder) {
        this.size = builder.size;
        this.cheese = builder.cheese;
        this.pepperoni = builder.pepperoni;
        this.lettuce = builder.lettuce;
        this.tomato = builder.tomato;
    }
}

is already immutable and the builder is the one thas is not with the added methods
what are the "addX" methods for ? if immutability is the goal ?

this example fails to display the purpose of the builder pattern IMHO

for another idea of implementation:

new Burger(size, ingredients)

with size and ingredients being higher representation (Dict/Set/HashMap)for example:
size can be a set of "big, small, medium"
ingredients can be "pepperonni: true" or "cheese: new Cheese("gouda")"
We have to kill this trend to make code for making code and remember that code is a higher level of expressing a solution/process.

I wrote the burger builder in my own preferred pattern. dev.to/jtlunsford/build-a-differen... Didn't care much for the chaining though I do find chaining nice if I need to pass the object around my application before we call it finished

A cool way of using builder design pattern when you want mandatory parameters:

public interface IRequestBuilderWithoutMethod {
    IRequestBuilderWithoutTimeout setMethod(HttpMethod method);
}


public interface IRequestBuilderWithoutTimeout {
    ICompletedRequest setTimeout(long timeout);
}

public interface ICompletedRequest {
    HttpResponse execute();
}

HttpRequestBuilder builder = HttpRequestBuilder.create('https://dev.to') //Return an IRequestBuilderWithoutMethod 
    .setMethod(HttpMethod.GET) //Return an IRequestBuilderWithoutTimeout 
    .setTimeout(2000L) //Return an ICompletedRequest 
    .execute();

I prefer Java 8 style builders

Burger.of(14, ingredients -> ingredients
    .pepperoni()
    .lettuce()
    .tomato());

You can easily create an overload which accepts only the mandatory arguments

Burger.of(14);

The configuration is implemented as a Consumer of type T, where T is a some sort of configuration object.

See Molten JSON for a JSON Builder implemented that way.

I just realised I've never really understood it before. I think the difference comes from the pragmatic use case, aka "the constructor has loads of arguments" + a nice a short none specific example. I'd like to read something this clear for every design pattern.

If a class has a constructor with a lot of arguments, the problem is in this class. Using a builder pattern just masks the problem, which is even worse. So I consider a builder an anti-pattern. I'd suggest to use a decorator instead:

interface Burger
{

}

class BreadWithCumin implements Burger
{
    private $size;

    public function __construct(Size $size)
    {
        $this->size = $size;
    }
}

class WithTomatoes implements Burger
{
    public function __construct(Burger $burger)
    {
    }
}

class WithCheese implements Burger
{
    public function __construct(Burger $burger)
    {
    }
}

If you object that Bread is a Burger, how about that:

class EmptyBurger implements Burger
{
    private $bread;

    public function __construct(Bread $bread)
    {
        $this->bread = $bread;
    }
}

class WithCumin implements Bread
{
    private $size;

    public function __construct(Size $size)
    {
        $this->size = $size;
    }
}

This code is highly composable, which probably means that it's good in terms of OOP.

There is a lot more to builder than just number, order and type of constructor arguments. Nice try though!!!

There is an error in sizevariable declaration in BurgerBuilder class:

public size;

instead of:

public int size;

The same is for Burger class.

Thank you for sharing.

In this code, can you tell me what font you use? It's very nice

There is a really great post about design patterns on GitHub, if you want to dig about this : github.com/kamranahmedse/design-pa...