From the ParameterClasses idiom:

-----

I'm not sure I undertand this idiom. Or better put, I'm not sure if it is different from the combination of a StrategyPattern (this used to incorrectly say ''FacadePattern'') with the AbstractFactoryPattern. I would say the BridgePattern, but it seems like you want the argument to be one of ''many'' parameterizations that decide how the outer layer performs. The second part seems like runtime type-selection using something like an AbstractFactory. Actually, I think you can also view ParameterClasses as just a parameterized FactoryMethodPattern. -- RobertDiFalco

Actually I think it is a variation on StrategyPattern - the Parameter classes are Strategy classes. You make a series of classes which describe various strategies and the user says which one to use.

''What isn't the strategy pattern?! ;)''

The use of dynamic loading, and the class name as the user-visible parameter name, are variations on the theme. As you say, an implementation of a Factory for creating the strategies. In C++ we might need to preload the classes and implement the name->instance mapping by hand. -- AnonymousDonor

''This is a JavaIdiom, so does not map easily into C++, especially as C++ has no language support for dynamic linking.  It is possible to implement ParameterClasses in C++ using the underlying dynamic linker provided by the host operating system.  You then have to define how a user-friendly parameter gets mapped to a DLL (shared object in Unix-speak), and how the class is exported from that DLL.  For instance, COM defines how monikers are mapped to CLSIDs (class identifiers) and how CLSIDs are mapped to DLLs, and how objects in those DLLs are created and queried for their interfaces.  However, none of that has anything to do with the C++ language itself.''


Yes, the StrategyPattern and Factory, maybe even a Parameterized FactoryMethodPattern. Actually, I'm not even sure why I said FacadePattern as I definitely intended on comparing Bridge and Strategy. Thanks. -- RobertDiFalco

The pattern is definitely related more closely to Bridge (allow different implementations without client classes knowing) than Strategy.  The intent of idiom is to map from configuration values to behaviours, allowing new parameters to be added to the program without having to change any code (even factory code).  This is achieved by translating parameters to class names and dynamically loading those classes.  How you use that class, once loaded, is beyond the scope of the pattern.  It may be a strategy, it may be a graphical component, it may be... well anything. -- NatPryce

The difference between Bridge and Strategy seems pretty subtle. Structurally they are similar. Strategy is also called Policy, which seemed to me to be similar to "Parameter". Bridge is also called Handle/Body, which to me does not feel like what this pattern was about. With Handle/Body we want the different bodies to look the same as far as the client is concerned, even if they are implemented differently. With Strategy the intent is that different strategies produce different behaviours of the client. Parameter classes are like Strategies in this regard. Not that it's a big deal, of course. -- AnonymousDonor

The difference between Bridge and Strategy, IMHO, is that an object uses a Strategy to alter ''its own behaviour'' while a Bridge is used to shield an object from different behaviours in other parts of the system.  Either way, a Bridge or a Strategy can be implemented as a ParameterClass.  

Take, for example, two uses of ParameterClasses in the JDK:

	* The AWT Toolkit is an example of the BridgePattern.
	* Character encodings that map between bytes to Unicode characters are used as Strategies by input and output streams.

To reiterate, ParameterClasses is a JavaIdiom for mapping from a user-visible parameter to a class that implements the behaviour specified by that parameter.
How that class is subsequently used is beyond the scope of this pattern, but may be defined by the StrategyPattern or BridgePattern.
--NatPryce