A characteristic of patterns is that experienced developers often experience a moment of recognition upon reading the write up. Sometimes the write up isn't even needed...
The PARAMETERISE FROM ABOVE pattern (PfA) has acquired a certain notoriety on accu-general. I first described it by this name a number of years ago as a general approach that reduced dependencies on global assumptions, whether constants or environmental features. The guideline covers a family of different techniques that all share an inversion of responsibilities and dependencies in a design.
A by-product of PfA - and also a commonly cited motivation for it - is the reduction of Singletons and other globals in a body of code. It is this characteristic that is most often associated with the pattern, as the following quote indicates [ Radford2006 ]:
One perspective on PARAMETERISE FROM ABOVE is that it is the alter-ego of SINGLETON (and other approaches involving globally SINGLETON is a dysfunctional pattern - one accessible objects). that transforms the design context for the worse, rather than for the better. PARAMETERISE FROM ABOVE is a pattern that is 'out there', but for which (to the best of my knowledge) there is (so far) no formal write up.
The closing sentence also hints at why this pattern has become notorious: in spite of frequent citation of the pattern and encouragement to do so, I have not yet documented it. I do not propose to break this tradition just yet, but in response to a recent posting of mine [ Henney2007 ] - and as an antidote to Teedy Deigh's seasonal foolishness [ Deigh2007 ] - I have decided to document some of PfA's history and uses. So let's take it from the top.
Parameterisation from the top
The general formulation and naming of the pattern has its origins at a particular client. It became a phrase and form of phrase I found myself commonly using in making design suggestions at this particular site. This much I remembered, and vaguely recalled it being around 2002 - there are presentations I have dated 2002 where the PfA term is used explicitly. What I had forgotten, until recently stumbling across it again, was that I had actually documented the basic idea in the appendix of a report for the client the previous year (July 2001, to be precise).
The client's system comprised a number of applications built from a common set of code. The report made a number of specific recommendations for repartitioning the utility packages and features in this system. The appendix in question was entitled 'Parameterisation from the Top', the full text of which is as follows:
One of the recurring issues in the use of constants in the [...] system is the hard coding of runtime-related names and constraint values, such as path names, queue names, event names, and so on. Although named constants have generally been used to avoid hardwiring the literal constants into the code, this has only made the coupling problem more obvious: the whole system is tightly coupled to application-level concepts. This means that even the smallest change to any of these values in future will result in a total system rebuild, i.e. all of the executables and libraries from which the system is comprised. It also means that code cannot be reused simply in other systems and that testing is always limited by these values, where others might be more appropriate for a test harness.
Such configuration values are not global, and therefore the use of global magic names has caused this problem. As the term configuration suggests, these are runtime configuration values that should supplied to each, and therefore by each, application (i.e. process). These values should be supplied explicitly by the initialising applications to the objects and classes that need them (either as constructor arguments or as template parameters, as appropriate). In other words, the practice being described here is that the parameterisation of a system should come from its top level downwards, and not from its bottom level upwards.
The first step is to move all use of global constants to the top layer of the system, and ensure that constants are passed down the layers as necessary. The next step is to factor out the commonality that exists between many of the applications, creating a simple application framework: a base class that handles command-line parsing, common initialisation, error handling and program execution. Global constants can then be migrated into the relevant derived classes. A final step would be to support runtime specification of many of these parameters through the application framework - configuration files, registry entries, command-line arguments, environment variables, etc.
Although this note is missing much of the customer context and system detail, the general idea comes through. In terms of PfA, it is pretty much all there, but with a particular focus on constants, and the idea of a more general design approach hinted at the end. The (dis)association with Singleton and the associated with Strategy objects, Context Objects, Mock Objects, etc., became more prominent the following year, as did the more relative - rather than absolute naming - of the practice.
References
[ Deigh2007] Teedy Deigh, 'A Practical Form of OO Layering', Overload 78 , April 2007, http://accu.org/index.php/journals/1327
[ Henney2007] Kevlin Henney, 'Parameterisation from the Top', accu-general, 2nd June 2007
[ Radford2006] Mark Radford, 'C++ Interface Classes: Strengthening Encapsulation', Overload 76 , December 2006, http://accu.org/index.php/journals/1329
