Introduction to: Patterns of Design (II)

In this next chapter another type of pattern of design will be introduced, the creational one. There are some differences between this kind of patterns and the behavioral types (a type of last one was described in part one), the most important thing is, while behavioral centers itself on the algorithms and how the object works, the creational pays attention in how the object is created.

We will decide to apply this kind of patterns when we need to focus in the creation of the object, and this creation is a highly complicated process. The concrete pattern shown in this introduction is the Builder Pattern.

The Builder Pattern is recommended when the algorithm for the creation of the object it’s very clear and it composed by very well-defined steps. The complexity of the creation lies on the different algorithms that might be used in the steps. Maybe a little class diagram should help:

As we can see in the class diagram, the Director is the only class that knows about the whole creation process. The Director it’s only coupled with the abstract Builder, so it has no dependency on the concrete classes. A concrete Builder class instance must be passed to the Director.

The Director knows which methods of the Builder class must be called, and in which order, what doesn’t know it’s what each method does, of course. Each concrete Builder class model a specific algorithm for the Product creation. In order to ensure that, the concrete classes must override the methods defined in the abstract class, except those ones that are generic enough.

Let’s apply this pattern in a real example, well maybe it isn’t very real, but it will be useful. Imagine that we need to model the Automated Letter Maker. Given a set of concepts (sender, subject, name…) the application must create different kinds of letters (friendly, formal, business letter…). All the letters has the same parts: header, greeting, body, complimentary clause, signature and postscript. Lets put it all together in another class diagram.

The Writer class knows the algorithm for writing a letter, first is the header, then de greeting… and ends with a possible postscript. But this class doesn’t know how to write it in the proper style (formal, business…). Each concrete builder knows how to write each part in the appropriate type. Finally the Letter is the output of any kind of builder.

Why this pattern is suitable for this example?

• The output it’s always the same: a Letter.
• The steps of the creation of a Letter are very clear.
• There are different ways to implement each step.
• The addition of new types of builders has the less possible impact in the model.

*All diagrams are made with StarUML.