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)

-- ArieVanDeursen

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 Windows''''''Button extends Button
 {
 	// implementation of a Windows button
 }

 class Motif''''''Button extends Button
 {
 	// implementation of a Motif button
 }

 class Button''''''Factory
 {
 	private Button btn ;
 	public Button create()
 	{
 		return (Button)btn.clone() ;
 	}
 }
The normal AbstractFactory approach would make Button''''''Factory abstract, and then add WindowsButtonF''''''actory and MotifButtonF''''''actory 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.

----
CategoryPattern, CategoryPatternFactory