We’re not going for simpler building. We’re going for simpler maintenance. By removing the Director what do you do? You tighten the coupling! We’ve been talking about that all the time on this blog. If you take shortcuts, you pay for it in the long run. Take a look at the principle of Loose Coupling and the post on Tight and Loose Programmers. Remember; we’re not worried about running out of silicon. We’re worried about taking way too many resources, time and bug by tight coupling.

Kindest regards,
Bill

It may be a while before I can get to Part II of the Builder because I have a new client who is going to keep me busy with a custom streaming Flash Media Server video project. (Of course I plan to use Design Patterns!)

As for listings that you need not scroll, just click the upper left corner View Code hot spot of the listing and a new window opens with all of the code nice and spread out. I don’t like listings that you have to scroll either!!

Cheers,
Bill

Given what changes (how a composite object gets created), it was a bit trickier than most; and so it’s not a surprise the Builder was elusive to you. (Took us a while too–it’s the last design pattern that Chandiam and I covered in ActionScript 3.0–on the blog and in the book.)

Where classes contain other classes, we’re dealing with tight coupling and that’s going to be a problem throughout. I think you probably mean where classes contain interfaces from other classes. Also, the Builder has aggregate relations between the Director and Builder, and it seems that the Client has aggregate relations with just about every other class! So, I would not worry about dealing with classes containing other classes if you mean they hold a common interface. Keep in mind that you don’t want to subclass a concrete class — remember the Liskov Substitution principle. Use those Lunch Bucket principles to help keep you out of trouble. (I certainly have to.)

So to answer your question, work with those 10 principles. What would they suggest? Then, when you work out your solution send it to us!! However, not to leave you hanging, you can have as many Product classes as you have concrete builders. So consider what type of product you want and build a Product class for that product. I just used one Product class, but it makes perfect sense to have as many as you have products to build. (In their example, GoF has 3 product classes.)

Kindest regards,
Bill

What tips do you have for building complex composition of objects, where classes contain other classes. Using your example above, what if the buildHotel() method needed to create a Hotel object? Would that method contain another builder to create the hotel for the product? Or would that be a poor approach?