Design Patterns : Elements of Reusable Object-Oriented Software

Design Patterns: Elements of Reusable Object-Oriented Software 
70 
// report error 
} else { 
GpiStrokePath(_hps, 1L, 0L); 
} 
} 
Why is this so different from the X version? Well, PM doesn't have anoperation 
for drawing rectangles explicitly as X does. Instead, PM has amore general 
interface for specifying vertices of multisegment shapes(called a 
path
) and for 
outlining or filling the area theyenclose. 
PM's implementation of DeviceRect is obviously quitedifferent from X's, but that 
doesn't matter. WindowImp hidesvariations in window system interfaces behind a 
potentially large butstable interface. That lets Window subclass writers focus 
on the windowabstraction and not on window system details. It also lets us 
addsupport for new window systems without disturbing the Window classes. 
Configuring Windows with WindowImps 
A key issue we haven't addressed is how a window gets configured withthe proper 
WindowImp subclass in the first place. Stated another way,when does _imp get 
initialized, and who knows what windowsystem (and consequently which WindowImp 
subclass) is in use? Thewindow will need some kind of WindowImp before it can 
do anythinginteresting. 
There are several possibilities, but we'll focus on one that uses theAbstract 
Factory (99) pattern. We can definean abstract factory class WindowSystemFactory 
that provides aninterface for creating different kinds of window 
system-dependentimplementation objects: 
class WindowSystemFactory { 
public: 
virtual WindowImp* CreateWindowImp() = 0; 
virtual ColorImp* CreateColorImp() = 0; 
virtual FontImp* CreateFontImp() = 0; 
// a "Create..." operation for all window system resources 
}; 
Now we can define a concrete factory for each window system: 
class PMWindowSystemFactory : public WindowSystemFactory { 
virtual WindowImp* CreateWindowImp() 
{ return new PMWindowImp; } 

---