C++ Builder design pattern: A pragmatic approach

[@goksanisil9107]

Appreciate your clarity (both in slides and narration), pragmatic approach and minimalism.

[@RishmaceInDaFace]

My first language is english and you speak 100x more clearly and amazing vocabulary 😂, very well explained video

[@TheFinagle]

Thank you for this clear description. This is what I needed for my own Menu backend I have been working on. I was trying to figure out how to have a lot of options for overlapping functionality without having to have a ton of different classes or calls - I can wrap each base functionality into a component and use a builder like design to construct a composition class that has whatever is needed for a particular element. Sometimes I find the text book descriptions of things like this kinda hard to visualize, and the extremely simple sample code snippets too simple to show whats going on. I like these more moderately complex samples that actually show things at work and give room to think a bit about how data is being moved around to get where it needs to be.

[@platisd]

Very happy to hear the example suited right for your use case! 👌

[@MartinCordova]

Very well explained

[@anthonysteinerv]

If I want to reuse the builder object to build, let's say, 2 menus, do we have to create a new Menu after the std::move on the build method?

[@platisd]

Correct. Alternatively, if you really want to avoid creating a new builder object (for whatever reason), you could instead store all the different "attributes" in the `Menu` class and only create a `Impl` object when someone calls the `build()` function. In that case the `withBorder`, `addOption` etc methods of the `Builder` class would merely set member variables and only create an `Impl` object upon the call of `build`. If you'd like us to discuss with more details and potentially code examples, please start an "issue" or a "discussion" in the GitHub repo (github.com/platisd/cpp-builder-pattern).