62: Design Patterns: Builder.

The builder creational pattern allows you to hide all the details needed to create a complicated object behind simple steps that another object will direct. This lets you change either how things get built or the steps that are used independently of each other. This pattern describes how you might have an abstract class called a builder with maybe three methods: addStory, addRoom, and addDoor The addStory method can be called many times to make the building higher. The builder will decide what needs to be done to support such a short or tall building. The addRoom method will add a room to a specific story. The director can call this method to add various rooms. The builder will decide how and where to place walls to get the desired effect. The addDoor method will be called to add a door between two rooms or between a room and the outside. And this design pattern describes how a client will be the one to actually choose a specific concrete builder class that derives from the abstract builder class. The client also selects a director and provides the builder to the director. The director only knows about the builder through the base class interface. With this pattern, different directors can be selected that will call the builder methods to direct the construction of various building. And different builder can be selected that will carry out these instructions. If the client selects a director that knows how to build a simple house in the suburbs but provides a shipBuilder for the builder, then what gets built will resemble a small sized yacht instead of a 3 bedroom house. Listen to the full episode or you can also read the full transcript below. Transcript The basic description says that this pattern separates the construction of complex objects from their representation so that the same construction process can create different representations. Alright, let me try to explain what that means so you can understand it. I haven’t used an example of building a house yet, so let’s use that for today’s analogy. One way to think of building a house would be to: ◦ #1 build the foundation ◦ #2 build the floor ◦ #3 build the walls ◦ #4 build the room ◦ #5 add the windows and doors ◦ and #6 add all the trim such as flooring, lighting, appliances, etc. That’s not the way this pattern works. I just wanted to mention it to get this out of the way. You see, all of those things are the details that this pattern is supposed to hide behind the representation. There’s a lot more details that I completely skipped but are actually very important. For example plumbing. Or heating. Wouldn’t be much of a house without those. But different buildings either for different purposes such as commercial vs. residential, or in different locations such as cold northern regions vs. tropics, or since this is software we’re talking about for actual building vs. testing purposes will each have drastically different ideas of what details are important. So let’s let the builder classes worry about those details. What we do is create an abstract builder class that has simple steps for building a house and then concrete builder classes that actually do whatever they need to do. So if steps like building the foundation, floor, and walls is not correct, then what kinds of steps should the abstract builder define? I’ll explain this right after this message from our sponsor. ( Message from Sponsor ) The steps I listed earlier are not just the wrong steps because of the details, they also don’t allow much variation in what gets built. The description of this pattern described how you could have different builders that each built something different. But I think it missed another important aspect. And that’s the ability to have different directors. What’s a director? In this pattern, you have a client which is in control of everything. This is very similar to real life. I’m not making this up. I