The Builder Pattern Explained and Implemented in Java | Creational Design Patterns | Geekific

[@NguyenTrang-je6zg]

for those who got error at 2:00, each of the setter method should return this, so that you can call method chaining in main

[@mahanirvaantantra]

Ideally it should NOT return this, instead the return type should be changed to void. As we are making changes to the object our purpose is not to return anything new. And in creating the car object in the builder class, these variables should be like this.id, this.brand, this.model, etc, because these are object methods...

[@TheEmbustil]

or abstract

[@masterflitzer]

@@mahanirvaantantra with void you can't do chaining...

[@mahanirvaantantra]

@@masterflitzer Yes. That's true. But for chaining he should have return 'this' or 'self'(in python). He didn't have it

[@gopsLiverpool]

This series is so clear and concise. There's great explanation, clear code and a relevant UML diagram which matches the code.

[@gopsLiverpool]

Just some add-on, it'll be awesome if you could add sequence diagram. Cheers

[@geekific]

Thanks a lot! Glad you liked it :)

[@VivekDudani]

Glad I found this series. Such a clear, crisp and step by step process of explaining different concepts. Thank you ❤.

[@1CheeseBurger]

Delivered with such quality and clarity. Gold.

[@tb7377]

At 2:00 the signature of the methods inside CarBuilder does not match the code. For example method id does not return a CarBuilder

[@geekific]

You are right! I think I missed them because they were pretty obvious in my head :D Anyway thanks for pointing that out! Cheers :)

[@anushakandagal1727]

So far the best video for builder pattern, thanks!

[@enishalilaj9309]

One of the best videos I've seen regarding this topic so far! Great work!

[@bjorn1409]

agreed

[@Felipinho5]

Wonderful explanation!

[@FarazAzadi]

Thanks a lot 🙏 If you want to use chain function calls, you should return "this" to return the object itself. ( It's forgotten in code. )

[@thatwasamazing2791]

Best explanation I’ve come across

[@svalyavasvalyava9867]

Wonderful explanation. Thank you! 😊

[@SerhiiArtymovych]

Great series! Thank you!

[@jpelegrinotube]

These series are great, I have watched many videos and studied books about design patterns but these videos are engaging me. Excelente work!!!

[@geekific]

Glad you like them! Thank you :)

[@abdielortega9778]

I loved the explanations 🥰

[@royalzsoftware]

Great! Thanks for sharing. Really clear, keep up with these videos

[@スターダスト-j5u]

Thanks, I'm Japanese. I can't understand English almost. But this video is perfect. I could understand builder pattern on this video than reading a textbook about gof in Japan. I admire you. thank you

[@geekific]

Thanks a lot for the kind words :) Glad I could be of help!

[@nirmalgurjar8181]

If you can't understand English then how are you writing it.

[@スターダスト-j5u]

@@nirmalgurjar8181 I know English a little

[@nirmalgurjar8181]

@@スターダスト-j5u ok .. you can write perfectly..

[@スターダスト-j5u]

@@nirmalgurjar8181 thanks

[@limitlesskode]

2:48 if the Car constructor is private how does the CarBuilder build method construct the car class?

[@geekific]

1/ Inner builders can still make use of it. 2/ In this video it is package-protected, and our builder sits in the same package (check this video: kzbin.info/www/bejne/Zl6XYoaDpLuSiqM).

[@jayak3768]

Here some problems I see: 1. 6:00 why Builder is an interface and not an abstract class. 2. The whole idea of Builder pattern is to allow clients to initialize the object with custom parameters as needed. The Director hides that complexity and provides a generic Build method. Meaning again the client is tied to the objects being initialized with specific params.

[@ulfdellbrugge827]

Great. I don't like real world examples like Cars but I still understood the concept very well even with audio only.

[@Captinofthemudslayer]

Theses patterns seem overly complicated for no reason

[@geekific]

When you apply them on simple examples they do!

[@razorblade413]

I'm starting to learn some patterns like state or memento. While those are useful, I honestly found this one overly complicated, because if the constructor has so many parameters why not just create an empty constructor and then populates the objects fields calling the setters methods like? Car car = new Car(); car.setBrand("Something"); // other setters fields that you want to initialize... car.setHeight(1.5); instead of using all those new classes?

[@caballerosalas]

Isolation

[@youme1461]

@@razorblade413because of immutability, if you want to make a property immutable, builder is the way to do it. With setters it’s not possible

[@tulasidamarla]

@@razorblade413 This approach has a flaw. The object's are always mutable, whereas if you use builder, the objects returned from it are immutable. This is explained by joshua bloch in effective java.

[@ivandrofly]

Top video on builder pattern

[@FarhanKhan]

superb explanation ... thanks for making the video

[@joostvandam8624]

great video!

[@ryankao1983]

crystal clear video thank you

[@geekific]

Glad you like it :)

[@Ellefsen97]

I like the Builder Pattern in some usecases, but the usecase would need to be justified imo. I would rarely use it in place of a constructor, if ever. Let's say that the constructor has 10 properties and we want to create 1 million cars. Instead of performing ~11 operations (calling constructor, setting the 10 properties), we need to perform ~3 operations per property (calling the build method, setting the property and return the Builder). It won't matter in most scenarios, but in this hyperbolic example the CPU would do approximately 11 million operations in the constructor example and 33 million in the builder example. Having long constructors is also rarely an issue since we just use variables as arguments: new Car(id, brand, make, doors, engine, ...). Then we can just make the optional properties nullable. I'm only critiquing it's usecase for being a replacement for constructors. It can be very useful in certain usecases like the StringBuilder, DateTimeFormatter etc. It's also useful when you want to chain modify default/set properties, like the Locale: Locale locale = builder.setLanguage("en").setRegion("US").build(); I love using the Builder Pattern in this scenario. We can change all the properties that we want in one line, and we can ignore the Locale properties that we want to leave as default.

[@nafiislam498]

Awesome explaination

[@clement1370]

Thx for this Pattern ! 😀

[@geekific]

You're welcome 😊

[@Labandusette]

very good

[@khalidsaifullah374]

We can not use director if param values are different?

[@trocandobytes]

I loved you explanations, but in the builder class is missing "return this" without thit you cannot link the methods with '.'

[@cristianpalechor2011]

You are so awesome !!

[@geekific]

And you rock

[@michaelfulton1080]

Thanks :)

[@whm920]

how is using the director class different from the Factory pattern?

[@Sobioytccc]

If the builder is not a part of class representation then how can it call it's constructor. And if there is no getter method for the class, how the client will be able to access it's field.

[@jhonatandariomarinjaramill9519]

thank you very much for the video, the build method should be put within the Builder interface, I thanks for the answer and again thank you very much for the video

[@geekific]

You are welcome! Glad it helped :)

[@jhonatandariomarinjaramill9519]

@@geekific excuse me for the bad writing, I asked you if the build method should be put within the Builder interface in the previous message but I forgot the question mark (?), could you respond me that?¿the build method has to be within the Builder interface or not?

[@geekific]

No worries :) Up to you! The basic ideas of the implementation will not change. Cheers!

[@haripriyachintalapati]

in CarBuilder setters, return CarBuilder

[@NhanNguyen-h6g]

In the CarBuilder class, why don't you put directly the Car as this class property rather than cloning all properties of Car into the builder? I mean that if we need to modify some properties of the Car, we must update the CarBuilder also.

[@Thori45]

I have a question, I read in the internet that you can use a public static inner class as a Builder in the object you want to create to implement the Builder Pattern. Is this basically the same? What are the advantages / disadvantages doing it either way?

[@geekific]

Yes you can do that, and on the larger scheme of things it won't really matter which option you pick. The main advantage of the inner class is the encapsulation of the construction logic within the class you are working with, leading to a more clean and concise code. However, it may increase the complexity as the class will be harder to understand if you are not familiar with the pattern, and may introduce some limitation in accessing private fields. Hope this helps :)

[@inkofthedragon]

Do you think the Builder Pattern could be an effective way to build different kinds of AiControllers with different behaviours/states and abilities, say for an Orc, Goblin, Troll, etc? Would the architecture flow look like? Thanks

[@geekific]

I am not sure I understood 100%, but I will try to answer. If you have a common Character class let's say extended by several other classes (Orc, Goblin etc.) the builder pattern can indeed be used to initialize the objects based on these classes. Cheers!

[@inkofthedragon]

@Geekific ok yes, so would i first have a Orc class and then an OrcBuilder class or a EnemyControllerBuilder class with methods like AddAbility, AddState, AddStat? And then inject in all the Abilities, Stats, States, etc? Then perhaps the EnemyControllerBuilder class would return a controller to the Orc class...and that would be the Orc? Thanks again

[@geekific]

I don't really like creating builders for classes that do not exist. If you have only an Orc class then create one builder for it. If you have an Enemy class extended by the Orc class, then yeah you may have two builders and pass stuff from one to another.

[@markos8383]

At 2:24 so basically we are just hiding the ugly part. We also need the constructor with those nulls.

[@geekific]

But still it is a cleaner approach because in that constructor you always pass the variable, there is no mention of 'null' elements in your code.

[@jorgegallego9672]

Shouldn´t you be returning "this" after every builder method? They all return CarBuilder but then the method is just a setter, this will give an error as "Expected CarBuilder but returned void"

[@coolfyb]

CarBuilder instead of duplicating Car fields, can contain Car and set it's fields via setters (restricted)?

[@geekific]

This will give you more flexibility and less coupling. Ex: If a Car's parameter is actually deduced from two other parameters that are not in the Car class, you can add these two params in the builder and the Car class doesn't need to know about them etc. Cheers!

[@tshepotsotetsi1067]

Was just having a conversation with someone about this

[@JuanRamirez-fx3tf]

How can you implement a builder in a children class? I only want to set some parameters of the parent class, and the id in the children class.

[@geekific]

By calling super() in the respective constructors.

[@yatri6329]

What is the meaning of making carSchema is this for to make different types of car like one implementation will make one kind of car and other is for different type. But this we can do inside director only. Than what is the meaning of carSchema. Plz explain

[@geekific]

In this video carSchema was used to explain one advantage of using a Director, and it is storing the common initialization of multiple objects which in turn have builders that implement the same interface. Hope this answers your question!

[@buku69420]

i am crying

[@MeraBaapHaiTu31]

Isn't it right that Director will also need the data or variable values which it will pass to Builder So How will we pass it to Director? Ans: We will create a Builder for that Director class 😂