| Abstract Factory Pattern |
Article Index for Abstract |
Website Links For Abstract |
Information AboutAbstract Factory Pattern |
| CATEGORIES ABOUT ABSTRACT FACTORY PATTERN | |
| software design patterns | |
| articles with example c code | |
| articles with example c sharp code | |
| articles with example java code | |
| articles with example php code | |
| articles with example visual prolog code | |
|
An example of this would be an abstract factory class ''documentCreator'' that provides interfaces to create a number of products (eg. ''createLetter()'' and ''createResume()''). The system would have any number of derived concrete versions of the ''documentCreator'' class like ''fancyDocumentCreator'' or ''modernDocumentCreator'', each with a different implementation of ''createLetter()'' and ''createResume()'' that would create a corresponding Object like ''fancyLetter'' or ''modernResume''. Each of these products is derived from a simple Abstract Class like ''Letter'' or ''Resume'' of which the Client is aware. The client code would get an appropriate Instantiation of the ''documentCreator'' and call its Factory Method s. Each of the resulting objects would be created from the same documentCreator implementation and would share a common theme. (They would all be fancy or modern objects.) The client would need to know how to handle only the abstract ''Letter'' or ''Resume'' class, not the specific version that it got from the concrete factory. In Software Development , a Factory is the location in the code at which Objects Are Constructed . The intent in employing the pattern is to insulate the creation of objects from their usage. This allows for new Derived Type s to be introduced with no change to the code that uses the Base Object . Use of this pattern makes it possible to interchange concrete classes without changing the code that uses them, even at Runtime . However, employment of this pattern, as with similar Design Pattern s, incurs the risk of unnecessary complexity and extra work in the initial writing of code. HOW TO USE IT The ''factory'' determines the actual ''concrete'' type of Object to be created, and it is here that the object is actually created (in C++, for instance, by the new Operator ). However, the factory only returns an ''abstract'' Pointer (or Wrapper Class ) to the created Concrete Object . This insulates client code from Object Creation by having clients ask a Factory Object to create an object of the desired Abstract Typ e and to return an Abstract Pointer to the object. As the factory only returns an abstract pointer, the client code (which requested the object from the factory) does not know - and is not burdened by - the actual concrete type of the object which was just created. In particular, this means:
And this is... STRUCTURE The Class Diagram of this design pattern is as shown below: EXAMPLES C#
abstract class GUIFactory { public static GUIFactory getFactory() { int sys = readFromConfigFile("OS_TYPE"); if (sys==0) { return(new WinFactory()); } else { return(new OSXFactory()); } } public abstract Button createButton(); } class WinFactory:GUIFactory { public override Button createButton() { return(new WinButton()); } } class OSXFactory:GUIFactory { public override Button createButton() { return(new OSXButton()); } } abstract class Button { public string caption; public abstract void paint(); } class WinButton:Button { public override void paint() { Console.WriteLine("I'm a WinButton: "+caption); } } class OSXButton:Button { public override void paint() { Console.WriteLine("I'm a OSXButton: "+caption); } } class Application { static void Main(string {Link without Title} args) { GUIFactory aFactory = GUIFactory.getFactory(); Button aButton = aFactory.createButton(); aButton.caption = "Play"; aButton.paint(); } //output is //I'm a WinButton: Play //or //I'm a OSXButton: Play } C++ #include using std::auto_ptr; class Control { }; class PushControl : public Control { }; class Factory { public: // Returns Factory subclass based on classKey. Each // subclass has its own getControl() implementation. // This will be implemented after the subclasses have // been declared. static auto_ptr virtual auto_ptr }; class ControlFactory : public Factory { public: virtual auto_ptr return auto_ptr } }; auto_ptr // Insert conditional logic here. Sample: switch(classKey) { default: return auto_ptr } } Perl # GUIFactory example on Perl package GUIFactory; sub getFactory($$) { shift; # skip class my = shift; if ( eq 'GTK') { return(GtkFactory->new); } else { return(TkFactory->new); } } package GtkFactory; use base 'GUIFactory'; sub new { bless({}, shift); } sub createButton { return(GtkButton->new); } package TkFactory; use base 'GUIFactory'; sub new { bless({}, shift); } sub createButton() { return(TkButton->new); } package Button; sub new { = shift; my = {}; {caption} = ''; bless(, ); return ; } package GtkButton; use base 'Button'; sub paint() { print "I'm a GtkButton "; } package TkButton; use base 'Button'; sub paint() { print "I'm a TkButton "; } package main; my = GUIFactory->getFactory; my = ->createButton; ->{caption} = "Play"; ->paint(); SEE ALSO |
|
|