pat3a.htm

Design Pattern 设计模式

create new instances on behalf of the concrete factory.  You define a
new factory by initializing an instance of a concrete factory with
<EM>classes</EM> of products rather than by subclassing.  This approach
takes advantage of language characteristics, whereas the pure
Prototype-based approach is language-independent.

<A NAME="auto1053"></A>
<P>Like the Prototype-based factory in Smalltalk just discussed, the
class-based version will have a single instance variable
<CODE>partCatalog</CODE>, which is a dictionary whose key is the name of
the part.  Instead of storing prototypes to be cloned,
<CODE>partCatalog</CODE> stores the classes of the products. The method
<CODE>make:</CODE> now looks like this:</P>

<A NAME="auto1054"></A>
<PRE>
    make: partName
        ^ (partCatalog at: partName) new
</PRE>

</LI>

<A NAME="auto1055"></A>
<P></P>

<A NAME="extensible"></A>
<LI><EM>Defining extensible factories.</EM>
AbstractFactory usually defines a different operation for each kind of
product it can produce.  The kinds of products are encoded in the
operation signatures.  Adding a new kind of product requires changing
the AbstractFactory interface and all the classes that depend on it.

<A NAME="auto1056"></A>
<P>A more flexible but less safe design is to add a parameter to
operations that create objects.  This parameter specifies the kind of
object to be created.  It could be a class identifier, an integer, a
string, or anything else that identifies the kind of product.  In fact
with this approach, AbstractFactory only needs a single "Make"
operation with a parameter indicating the kind of object to create.
This is the technique used in the Prototype- and the class-based
abstract factories discussed earlier.</P>

<A NAME="auto1057"></A>
<P>This variation is easier to use in a dynamically typed language like
Smalltalk than in a statically typed language like C++.  You can use
it in C++ only when all objects have the same abstract base class or
when the product objects can be safely coerced to the correct type by
the client that requested them.  The implementation section of <A HREF="pat3cfs.htm" TARGET="_mainDisplayFrame">Factory Method (107)</A> shows how to implement such
parameterized operations in C++.</P>

<A NAME="downcast"></A>
<A NAME="dynamic_cast"></A>
<P>But even when no coercion is needed, an inherent problem remains: All
products are returned to the client with the <EM>same</EM> abstract
interface as given by the return type.  The client will not be able to
differentiate or make safe assumptions about the class of a product.
If clients need to perform subclass-specific operations, they won't be
accessible through the abstract interface.  Although the client could
perform a downcast (e.g., with <CODE>dynamic_cast</CODE> in C++), that's
not always feasible or safe, because the downcast can fail.  This is the
classic trade-off for a highly flexible and extensible interface.</P>

</LI>

</OL>

<A NAME="samplecode"></A>
<H2><A HREF="#knownuses"><IMG SRC="gifsb/down3.gif" BORDER=0 ALT="next: 
Known Uses"></A> Sample Code</H2> 

<A NAME="auto1058"></A>
<P>We'll apply the Abstract Factory pattern to creating the mazes we
discussed at the beginning of this chapter.</P>

<A NAME="auto1059"></A>
<P>Class <CODE>MazeFactory</CODE> can create components of mazes.  It builds
rooms, walls, and doors between rooms.  It might be used by a program
that reads plans for mazes from a file and builds the corresponding
maze.  Or it might be used by a program that builds mazes randomly.
Programs that build mazes take a <CODE>MazeFactory</CODE> as an argument
so that the programmer can specify the classes of rooms, walls, and
doors to construct.</P>

<A NAME="MazeFactory-def"></A>
<PRE>
    class MazeFactory {
    public:
        MazeFactory();
    
        virtual Maze* MakeMaze() const
            { return new Maze; }
        virtual Wall* MakeWall() const
            { return new Wall; }
        virtual Room* MakeRoom(int n) const
            { return new Room(n); }
        virtual Door* MakeDoor(Room* r1, Room* r2) const
            { return new Door(r1, r2); }
    };
</PRE>

<A NAME="auto1060"></A>
<P>Recall that the member function
<CODE>CreateMaze</CODE> (<a href="chap3fs.htm#CreateMaze-def" TARGET="_mainDisplayFrame">page 84</A>)
builds a small maze consisting of two rooms with a door between them.
<CODE>CreateMaze</CODE> hard-codes the class names, making it difficult
to create mazes with different components.</P>

<A NAME="auto1061"></A>
<P>Here's a version of <CODE>CreateMaze</CODE> that remedies that
shortcoming by taking a <CODE>MazeFactory</CODE> as a parameter:</P>

<A NAME="auto1062"></A>
<PRE>
    Maze* MazeGame::CreateMaze (MazeFactory&amp; factory) {
        Maze* aMaze = factory.MakeMaze();
        Room* r1 = factory.MakeRoom(1);
        Room* r2 = factory.MakeRoom(2);
        Door* aDoor = factory.MakeDoor(r1, r2);
    
        aMaze->AddRoom(r1);
        aMaze->AddRoom(r2);
    
        r1->SetSide(North, factory.MakeWall());
        r1->SetSide(East, aDoor);
        r1->SetSide(South, factory.MakeWall());
        r1->SetSide(West, factory.MakeWall());
    
        r2->SetSide(North, factory.MakeWall());
        r2->SetSide(East, factory.MakeWall());
        r2->SetSide(South, factory.MakeWall());
        r2->SetSide(West, aDoor);
    
        return aMaze;
    }
</PRE>

<A NAME="enchnt-maze-fac"></A>
<P>We can create <CODE>EnchantedMazeFactory</CODE>, a factory for enchanted
mazes, by subclassing <CODE>MazeFactory</CODE>.
<CODE>EnchantedMazeFactory</CODE> will override different member
functions and return different subclasses of
<CODE>Room</CODE>, <CODE>Wall</CODE>, etc.</P>

<A NAME="auto1063"></A>
<PRE>
    class EnchantedMazeFactory : public MazeFactory {
    public:
        EnchantedMazeFactory();
    
        virtual Room* MakeRoom(int n)  const
            { return new EnchantedRoom(n, CastSpell()); }
    
        virtual Door* MakeDoor(Room* r1, Room* r2)  const
            { return new DoorNeedingSpell(r1, r2); }
    
    protected:
        Spell* CastSpell() const;
    };
</PRE>

<A NAME="auto1064"></A>
<P>Now suppose we want to make a maze game in which a room can have a
bomb set in it.  If the bomb goes off, it will damage the walls (at
least).  We can make a subclass of <CODE>Room</CODE> keep track of
whether the room has a bomb in it and whether the bomb has gone off.
We'll also need a subclass of <CODE>Wall</CODE> to keep track of the
damage done to the wall.  We'll call these classes
<CODE>RoomWithABomb</CODE> and <CODE>BombedWall</CODE>.</P>

<A NAME="auto1065"></A>
<P>The last class we'll define is <CODE>BombedMazeFactory</CODE>, a subclass
of <CODE>MazeFactory</CODE> that ensures walls are of class
<CODE>BombedWall</CODE> and rooms are of class <CODE>RoomWithABomb</CODE>.
<CODE>BombedMazeFactory</CODE> only needs to override two functions:</P>

<A NAME="auto1066"></A>
<PRE>
    Wall* BombedMazeFactory::MakeWall () const {
        return new BombedWall;
    }
    
    Room* BombedMazeFactory::MakeRoom(int n) const {
        return new RoomWithABomb(n);
    }
</PRE>

<A NAME="auto1067"></A>
<P>To build a simple maze that can contain bombs, we simply call
<CODE>CreateMaze</CODE> with a <CODE>BombedMazeFactory</CODE>.</P>

<A NAME="auto1068"></A>
<PRE>
    MazeGame game;
    BombedMazeFactory factory;
    
    game.CreateMaze(factory);
</PRE>

<A NAME="auto1069"></A>
<P><CODE>CreateMaze</CODE> can take an instance of
<CODE>EnchantedMazeFactory</CODE> just as well to build enchanted
mazes.</P>

<A NAME="auto1070"></A>
<P>Notice that the <CODE>MazeFactory</CODE> is just a collection of factory
methods.  This is the most common way to implement the Abstract
Factory pattern.  Also note that <CODE>MazeFactory</CODE> is not an
abstract class; thus it acts as both the AbstractFactory <EM>and</EM> the
ConcreteFactory.  This is another common implementation for simple
applications of the Abstract Factory pattern.  Because the <CODE>MazeFactory</CODE> is a concrete class consisting
entirely of factory methods, it's easy to make a new
<CODE>MazeFactory</CODE> by making a subclass and overriding the
operations that need to change.</P>

<CODE>CreateMaze</CODE> used the <CODE>SetSide</CODE> operation on rooms to
specify their sides.  If it creates rooms with a
<CODE>BombedMazeFactory</CODE>, then the maze will be made up of
<CODE>RoomWithABomb</CODE> objects with <CODE>BombedWall</CODE> sides.  If
<CODE>RoomWithABomb</CODE> had to access a subclass-specific member of
<CODE>BombedWall</CODE>, then it would have to cast a
reference to its walls from <CODE>Wall*</CODE> to
<CODE>BombedWall*</CODE>.  This downcasting is safe as long as the argument
<EM>is</EM> in fact a <CODE>BombedWall</CODE>, which is guaranteed to be
true if walls are built solely with a <CODE>BombedMazeFactory</CODE>.</P>

<A NAME="auto1072"></A>
<P>Dynamically typed languages such as Smalltalk don't require downcasting,
of course, but they might produce run-time errors if they encounter a
<CODE>Wall</CODE> where they expect a <EM>subclass</EM> of <CODE>Wall</CODE>.
Using Abstract Factory to build walls helps prevent these run-time
errors by ensuring that only certain kinds of walls can be
created.</P>

<A NAME="auto1073"></A>
<P>Let's consider a Smalltalk version of <CODE>MazeFactory</CODE>, one with
a single <CODE>make</CODE> operation that takes the kind of object to
make as a parameter.  Moreover, the concrete factory stores the
classes of the products it creates.</P>

<A NAME="auto1074"></A>
<P>First, we'll write an equivalent of <CODE>CreateMaze</CODE> in
Smalltalk:</P>

<A NAME="auto1075"></A>
<PRE>
    createMaze: aFactory
        | room1 room2 aDoor |
        room1 := (aFactory make: #room) number: 1.
        room2 := (aFactory make: #room) number: 2.
        aDoor := (aFactory make: #door) from: room1 to: room2.
        room1 atSide: #north put: (aFactory make: #wall).
        room1 atSide: #east put: aDoor.
        room1 atSide: #south put: (aFactory make: #wall).
        room1 atSide: #west put: (aFactory make: #wall).
        room2 atSide: #north put: (aFactory make: #wall).
        room2 atSide: #east put: (aFactory make: #wall).
        room2 atSide: #south put: (aFactory make: #wall).
        room2 atSide: #west put: aDoor.
        ^ Maze new addRoom: room1; addRoom: room2; yourself
</PRE>

<A NAME="auto1076"></A>
<P>As we discussed in the Implementation section, <CODE>MazeFactory</CODE>
needs only a single instance variable <CODE>partCatalog</CODE> to provide
a dictionary whose key is the class of the component.  Also recall how
we implemented the <CODE>make:</CODE> method:</P>

<A NAME="auto1077"></A>
<PRE>
    make: partName
        ^ (partCatalog at: partName) new
</PRE>

<A NAME="auto1078"></A>
<P>Now we can create a <CODE>MazeFactory</CODE> and use it to implement
<CODE>createMaze</CODE>.  We'll create the factory using a method
<CODE>createMazeFactory</CODE> of class <CODE>MazeGame</CODE>.</P>

<A NAME="auto1079"></A>
<PRE>
    createMazeFactory
        ^ (MazeFactory new
            addPart: Wall named: #wall;
            addPart: Room named: #room;
            addPart: Door named: #door;
            yourself)
</PRE>

<A NAME="auto1080"></A>
<P>A <CODE>BombedMazeFactory</CODE> or <CODE>EnchantedMazeFactory</CODE> is
created by associating different classes with the keys. For example,
an <CODE>EnchantedMazeFactory</CODE> could be created like this:</P>

<A NAME="auto1081"></A>
<PRE>
    createMazeFactory
        ^ (MazeFactory new
            addPart: Wall named: #wall;
            addPart: EnchantedRoom named: #room;
            addPart: DoorNeedingSpell named: #door;
            yourself)
</PRE>


<A NAME="knownuses"></A>
<H2><A HREF="#relatedpatterns"><IMG SRC="gifsb/down3.gif" BORDER=0 
ALT="next: Related Patterns"></A> Known Uses</H2> 

<A NAME="auto1082"></A>
<P>InterViews uses the "Kit" suffix [<a href="bibfs.htm#interviews_kit" TARGET="_mainDisplayFrame">Lin92</A>] to denote AbstractFactory
classes.  It defines WidgetKit and DialogKit abstract factories
for generating look-and-feel-specific user interface objects.
InterViews also includes a LayoutKit that generates different
composition objects depending on the layout desired.  For example,
a layout that is conceptually horizontal may require different
composition objects depending on the document's orientation (portrait
or landscape).</P>

<A NAME="use-ab-fac"></A>
<P>ET++ [<a href="bibfs.htm#et++" TARGET="_mainDisplayFrame">WGM88</A>] uses the Abstract Factory pattern to achieve
portability across different window systems (X Windows and SunView,
for example).  The WindowSystem abstract base class defines the
interface for creating objects that represent window system resources
(MakeWindow, MakeFont, MakeColor, for example).  Concrete subclasses
implement the interfaces for a specific window system. At run-time,
ET++ creates an instance of a concrete WindowSystem subclass that
creates concrete system resource objects.</P>

<A NAME="relatedpatterns"></A>
<H2><A HREF="#last"><IMG SRC="gifsb/down3.gif" BORDER=0 ALT="next: 
navigation"></A> Related Patterns</H2> 

<A NAME="auto1083"></A>
<P>AbstractFactory classes are often implemented with factory
methods (<A HREF="pat3cfs.htm" TARGET="_mainDisplayFrame">Factory
Method (107)</A>), but they can also be implemented using <A
HREF="pat3dfs.htm" TARGET="_mainDisplayFrame">Prototype (117)</A>.</P>

<A NAME="auto1084"></A>
<P>A concrete factory is often a singleton (<A HREF="pat3efs.htm"
TARGET="_mainDisplayFrame">Singleton (127)</A>).

<A NAME="last"></A>
<P><A HREF="#intent"><IMG SRC="gifsb/up3.gif" BORDER=0></A><BR>
<A HREF="pat3bfs.htm" TARGET="_mainDisplayFrame"><IMG SRC="gifsb/rightar3.gif"
	ALIGN=TOP BORDER=0></A> <A HREF="pat3bfs.htm"
	TARGET="_mainDisplayFrame">Builder</A><BR>
<A HREF="chapfs.htm" TARGET="_mainDisplayFrame"><IMG SRC="gifsb/leftarr3.gif"
	ALIGN=TOP BORDER=0></A> <A HREF="chap3fs.htm"
	TARGET="_mainDisplayFrame">Creational Patterns</A>
</P>

</BODY>

</HTML>