The Problem

The patterns discussed in Chapters 6–7 adhere closely to the GoF philosophy of designing to an interface rather than an implementation. That maxim inspired the use of abstract classes in defining an abstract calculus, a strategy, and a surrogate. The puppeteer definition in Chapter 8 represented the one setting in which client code manipulated concrete implementations directly – although an exercise at the end of that chapter describes a way to liberate the puppeteer from the tyranny of implementations also.

Independent of whether the classes comprising the pattern demonstrations are abstract, the client codes (main programs in the cases considered) exploit knowledge of the concrete type of each object constructed in Chapters 6–8. Although we were able to write polymorphic procedures such as integrate in Figures 6.2(b) and 6.3(b)–(c), in each case, the actual arguments passed to these procedures were references to concrete objects the client constructed. One can write even more flexible code by freeing clients of even this minimal knowledge of concrete types. This poses the dilemma of where object construction happens. Put simply, how does one construct an object without directly invoking its constructor? Or from another angle, how does an object come to be if the client knows only the interface defined by its abstract parent, but that parent's abstract nature precludes definition of a constructor? By definition, no instance of an abstract type can be instantiated.