4.4 Hooks as name designators of pattern catalog entries

4.4 Hooks as name designators of pattern catalog entries

Hook methods form the points of predefined refinement that we call variation points or hot spots (Pree, 1995). Framework adaptation takes place at these variation points. Depending on hook placement and template hook method combination more or less flexibility can be achieved.

Every framework incorporates the two essential construction principles, Unification and Separation, no matter how simple or how complex the particular template and hook methods are. Fine-grained classes apply the same construction principles as complex classes in order to introduce flexibility. They differ only in the granularity, the semantics of the hooks (often expressed in a hook's name), the number of provided defaults for a hook, and the number of template hook pairs. Thus we can take a fresh look at widely known pattern catalogs. As the focus of the following considerations lies on the pioneering pattern catalog by Gamma et al. (1995), the reader should be familiar with these patterns. In the following, when we refer to the pattern catalog or the GoF patterns we mean the 23 patterns published in the book by Gamma et al. (1995).

Many entries in the pattern catalog can be regarded as small frameworks,^[6] consisting of a few classes, that apply the essential construction principles in various more or less domain-independent situations. These catalog entries are helpful when designing frameworks and they illustrate typical hook semantics. In general, the names of the catalog entries are closely related to the semantic aspects that are kept flexible by provided hooks.

^[6] These are Template Method, Factory Method; Bridge, Abstract Factory, Builder, Command, Interpreter, Observer, Prototype, State, Strategy; Composite, Decorator, Chain of Responsibility

4.4.1 GoF patterns with a template hook unification

The catalog pattern Template Method discusses the basic concept of template and hook methods in a quite generic way analogous with the Unification construction principle. The Factory Method pattern keeps the creation of objects flexible and relies on a unification of template and hook methods in one class. The template and hook methods are in class Creator, the hook method has the name factoryMethod(). The hook semantics determine the pattern name. Figure 4.21 annotates the structure of the Factory Method pattern (see Gamma et al., 1995) and points out which of the methods in class Creator is the template and which one is the hook method.

Figure 4.21. Unification-based Factory Method pattern

The Abstract Factory pattern results from the Factory Method pattern by separating template and hook methods in two classes. This is analogous with keeping the hook method round() in the same class as the template method versus separating the two methods.

4.4.2 GoF patterns with a template hook separation

A significant portion of the framework-centered pattern catalog entries relies on a separation of template and hooks, that is on the basic Separation principle. The catalog pattern Bridge discusses the abstract coupling mechanism generically. Other catalog entries that use template hook separation introduce more specific semantics for their hooks: Abstract Factory, Builder, Command, Interpreter, Observer, Prototype, State, and Strategy. The names of these catalog patterns correspond to the semantics of a particular hook method or the corresponding class. Table 4.5 relates these GoF pattern names to the name of the class containing the hook, the hook method name, and the name of the class containing the template as used in the pattern description in the catalog. The hook semantics are summarized from a table in Gamma et al. (1995). The method names start with a capital letter as in the GoF pattern catalog.

Table 4.5. Naming issues of catalog entries

Catalog entry	Class with hook	Hook method	Class with template	Hook semantics
Abstract Factory	AbstractFactory	CreateProduct()	Client	Families of product objects.
Builder	Builder	BuildPart()	Director	How a complex object is created.
Command	Command	Execute()	Invoker	When and how a request is fulfilled.
Interpreter	AbstractExpression	Interpret( )	Client	Interpretation of a language.
Observer	Observer	Update()	Subject	How the dependent objects stay up to date.
Prototype	Prototype	Clone()	Client	Class of object that is instantiated.
State	State	Handle()	Context	States of an object.
Strategy	Strategy	AlgorithmInterface()	Context	An algorithm.

Of these Separation-based patterns, the Abstract Factory, Builder, Observer, State, and Strategy patterns represent rather generic examples of hook semantics. In particular, the necessity to keep object creation flexible as in the two patterns Abstract Factory and Builder is likely to occur in many frameworks.

4.4.3 GoF patterns with recursive template hook combinations

Besides the unification and separation of template and hooks, three principles result from template hook combinations that allow recursive graph compositions of objects for example, in trees and lists. For the sake of completeness, we include the derivation of these principles as a result of considering the possible template hook combinations. The pattern catalog discusses the details of how and when to apply these construction principles.

In the pattern catalog entry Composite, the class with the template method (T) inherits from the class with the hook method (H). The association between the two classes is a zero to N relationship that is, a T object can refer to any number of H objects (see Figure 4.22(a)). The name Composite expresses the core characteristic of this construction principle, namely that a tree hierarchy of objects can be built and treated in the same way as a single object.

Figure 4.22. Core class structure of (a) Composite and (b) Decorator patterns

The recursive composition where template and hooks are separated and where a T object can refer to zero or one H object (see Figure 4.22(b)) represents the Decorator pattern. The name expresses that objects can be dynamically adorned with additional behavior. Note that T need not be a direct subclass of H that is, several other classes might be in between T and H. This is valid for both class diagrams (a) and (b) in Figure 4.22.

Finally, a kind of degenerated recursive composition where template and hooks melt in one class TH, and where a TH object can refer to zero or one other TH object (see Figure 4.23) is the Chain of Responsibility pattern in the catalog.

Figure 4.23. Class structure of the Chain of Responsibility pattern