Pluggable Factory
An extension to the AbstractFactoryPattern is the PluggableFactory proposed by JohnVlissides. See:
- JohnVlissides. "Pluggable Factory, Part I," CppReport, Nov./Dec. 1998. (http://www.research.ibm.com/designpatterns/pubs/ph-nov-dec98.pdf)
- JohnVlissides. "Pluggable Factory, Part II," CppReport, February 1999. (http://www.research.ibm.com/designpatterns/pubs/ph-feb99.pdf)
- Timothy R. Culp. "Industrial Strength Pluggable Factories". CppReport, October 1999. (http://adtmag.com/articles/2000/09/25/industrial-strength-pluggable-factories.aspx)
Briefly, there is a single factory class, instances of which contain prototype instances of the things to be created; these instances are then cloned to satisfy creation requests. Thus, the PluggableFactory pattern hides the PrototypePattern, using the factory as a facade (FacadePattern).
For example (in JavaLanguage):
abstract class Button
{
abstract public Object clone();
}
class WindowsButton extends Button
{
// implementation of a Windows button
}
class MotifButton extends Button
{
// implementation of a Motif button
}
class ButtonFactory
{
private Button btn ;
public Button create()
{
return (Button)btn.clone() ;
}
}
The normal AbstractFactory approach would make ButtonFactory abstract, and then add WindowsButtonFactory and MotifButtonFactory subclasses; it also wouldn't need Button to be Cloneable.
The advantage of a PluggableFactory is that it eliminates the proliferation of factory subclasses. The disadvantage is that the products must be cloneable, or otherwise duplicatable in some way.
A nominally related, but distinct, pattern for using AbstractFactory as the export component in PluginArchitecture is described in the page on AbstractFactory.