Design Patterns : Elements of Reusable Object-Oriented Software

Factories and Product Classes 
Normally we might create an instance of a Motif scroll bar glyph with thefollowing 
C++ code: 
ScrollBar* sb = new MotifScrollBar; 
This is the kind of code to avoid if you want to minimizeLexi's look-and-feel 
dependencies. But suppose weinitialize sb as follows: 
ScrollBar* sb = guiFactory->CreateScrollBar(); 
where guiFactory is an instance of a
MotifFactory
class. CreateScrollBarreturns 
a new instance of the proper ScrollBar subclass for thelook and feel desired, 
Motif in this case. As far as clients areconcerned, the effect is the same as 
calling the MotifScrollBarconstructor directly. But there's a crucial difference: 
There'sno longer anything in the code that mentions Motif by name. TheguiFactory 

---

Design Patterns: Elements of Reusable Object-Oriented Software 
62 
object abstracts the process of creatingnot just Motif scroll bars but scroll 
bars for 
any
look-and-feel standard. And guiFactory isn't limitedto producing 
scroll bars. It can manufacture a full range of widgetglyphs, including scroll 
bars, buttons, entry fields, menus, andso forth. 
All this is possible because MotifFactory is a subclass of
GUIFactory
, an abstract 
class that defines ageneral interface for creating widget glyphs. It includes 
operationslike CreateScrollBar and CreateButtonfor instantiating different kinds 
of widget glyphs. Subclasses ofGUIFactory implement these operations to return 
glyphs such asMotifScrollBar and PMButton that implement a particular look andfeel. 
Figure 2.9 showsthe resulting class hierarchy for guiFactory objects. 
Figure 2.9: GUIFactory class hierarchy 
We say that factories create 
product
objects.Moreover, the products that a factory 
produces are related to oneanother; in this case, the products are all widgets 
for the samelook and feel. Figure 2.10 shows some of the product classes needed 
to make factories workfor widget glyphs. 

---