4.6 How essential framework construction principles scale

The framework construction principles are independent of the complexity of template and hook methods. In other words, the construction principles can be applied recursively to compose larger units that can be extended depending on the applied construction principle. Why is that the case? What constitutes a template method and a hook method is a matter of viewpoint. By definition, a hook method is elementary compared to the template method in which the particular hook method is used. In another context, the template method can become a hook of another template method. For example, convert() in class CurrencyConverter is a template method invoking round() as its hook (see Figure 4.37).

Figure 4.37. Template and hooks in class CurrencyConverter

In the context of class Account, another method, for example calcBalance(), is the template method that calls convert() of a CurrencyConverter object as its hook (see Figure 4.38). Method convert() which is a template method in one context becomes a hook in another context. Method calcBalance() can again become the hook method in the context of another class. In other words, hooks are not necessarily tiny methods, but scale up to more complex behavior.

Figure 4.38. Template and hooks in classes Account and CurrencyConverter

Finding a balance between template and hook methods

Ideally, programmers only have to override the most elementary hook method to adjust the behavior of the outermost template method. In the example above, overriding CurrencyConverter's method round() should suffice to adjust calcBalance(), at least the rounding aspect of this method. Various authors (e.g. Weinand et al., 1989) refer to this framework design principle as the narrow inheritance interface principle.

Unfortunately, designing classes with narrow inheritance interfaces involves conflicting goals good design of class interfaces in the realm of frameworks should find the optimal balance between flexibility and the effort required to adapt classes. If a template offers too many hooks it might get too complex to adapt. A class that provides powerful template methods which are only based on a few hooks implies minimal effort for adaptation. Behavior is adapted by overriding some or all of these hooks in subclasses. However, powerful template methods could sacrifice the flexibility of a class. If their hook methods are not sufficient to modify the template method's behavior, a class becomes inflexible, implying that the whole template method has to be overridden. In the example above, method calcBalance() has to be overridden as a whole if it does not offer the appropriate hooks.

Thus, template methods have the potential to reduce adaptation effort without sacrificing flexibility, but add the danger of making classes too rigid, which then increases the adaptation effort.

The design of framework classes/interfaces typically requires many iterations, caused by the use of a framework in specific situations. During such iterations, some template methods might appear to be too rigid, so that more hook methods have to be integrated. It is also possible that the actual use of the defined classes provides insight into how to come up with additional template methods. If programmers have to implement similar control flow repeatedly in the course of adapting a framework, additional template methods should be defined in framework classes.

It is impossible to lay down general guidelines for getting template methods right from the start. Above all, it is important to grasp the conflicting goals of combining template and hook methods according to the narrow inheritance principle. The optimum balance depends on domain-specific adaptations of frameworks.