The Abstract Factory pattern, although not present in many end-user applications, finds ample grace in the development of user-configurable toolkits and frameworks. Instead of locking the developer into a particular set of controls or objects that will be used by the framework, the abstract factory instead lets developers substitute their own controls when necessary.
The guiding metaphor of the Abstract Factory is that of a manufacturing plant. Whereas a manufacturing plant creates products, the Abstract Factory manufactures its own classes when necessary. This is particularly applicable to Inversion of Control (IoC) applications. Inversion of Control is where program flow is handled by an external class, such as a framework or Rapid Application Development platform, and the main program code simplify configures the framework and launches it.
Key applications of the abstract factory are in the dynamic generation of components used by the frameworks. In the following example, the framework “ControlFactory” is used to dynamically create form controls. An accounting application called “AccountingApp” uses the ControlFactory framework to initialize its controls. When the main program starts, it can either initialize the AccountingApp with the standard ControlFactory, or initialize a custom version called AccessibleControlFactory with big text for better legibility:
public class Program {
public static ControlFactory CF;
public static void Main(){
CF = new AccessibleControlFactory();
(new AccountingApp()).Run();
}
}
public class ControlFactory {
public virtual Form CreateForm() { return new Form(); }
public virtual TextBox CreateTextBox() { return new TextBox(); }
}
public class AccessibleControlFactory : ControlFactory {
public override TextBox CreateTextBox() {
TextBox rslt = new TextBox();
rslt.Font = new Font(FontFamily.GenericSansSerif,18);
return rslt;
}
}
public class AccountingApp {
public void Run(){
Form f = Program.CF.CreateForm();
f.Controls.Add(Program.CF.CreateTextBox());
Application.Run(f);
}
}
The ControlFactory is initialized at application start. Normally, this would be implemented in a Singleton, however this example uses a static variable for legibility. In most production applications, Abstract Factories are implemented in Singletons to ensure a single class instance. This can be particularly beneficial in applications such as database connection pooling, where database connections are requested from a single class and re-used as necessary to help reduce connection start-up and tear-down overhead.
The Abstract Factory can also be found in ORM (Object Relational Mapper) frameworks, that dynamically create classes for tables. The table classes can be overridden to perform additional functionality, such as setting default values for a particular application, or handling save or validation in a different way.
With the flexibility that Abstract Factories provide for end-users of frameworks and toolkits, software architects would do well to utilize the pattern where possible, making derivative applications more configurable and easier to adapt to changing business requirements.
Written by Andrew Palczewski
About the Author
Andrew Palczewski is CEO of apHarmony, a Chicago software development company. He holds a Master's degree in Computer Engineering from the University of Illinois at Urbana-Champaign and has over ten years' experience in managing development of software projects.
Google+
