📄 pat3a.htm
字号:
<HTML>
<HEAD><TITLE>Abstract Factory</TITLE></HEAD>
<BODY BGCOLOR = #FFFFFF
TEXT = #000000
>
<A NAME="top"></A>
<A NAME="AbstractFactory"></A>
<A NAME="intent"></A>
<H2><A HREF="#alsoknownas"><IMG SRC="gifsb/down3.gif" BORDER=0></A> Intent</H2>
<A NAME="auto1000"></A>
<P>Provide an interface for creating families of related or dependent
objects without specifying their concrete classes.</P>
<A NAME="alsoknownas"></A>
<H2><A HREF="#motivation"><IMG SRC="gifsb/down3.gif" BORDER=0></A>Also Known As</H2>
<A NAME="auto1001"></A>
<P>Kit</P>
<A NAME="motivation"></A>
<H2><A HREF="#applicability"><IMG SRC="gifsb/down3.gif" BORDER=0></A> Motivation</H2>
<A NAME="auto1002"></A>
<P>Consider a user interface toolkit that supports multiple look-and-feel
standards, such as Motif and Presentation Manager. Different
look-and-feels define different appearances and behaviors for user
interface "widgets" like scroll bars, windows, and buttons. To be
portable across look-and-feel standards, an application should not
hard-code its widgets for a particular look and feel. Instantiating
look-and-feel-specific classes of widgets throughout the application
makes it hard to change the look and feel later.</P>
<A NAME="widgetfactory"></A>
<P>We can solve this problem by defining an abstract WidgetFactory class
that declares an interface for creating each basic kind of widget.
There's also an abstract class for each kind of widget, and concrete
subclasses implement widgets for specific look-and-feel standards.
WidgetFactory's interface has an operation that returns a new widget
object for each abstract widget class. Clients call these operations
to obtain widget instances, but clients aren't aware of the concrete
classes they're using. Thus clients stay independent of the
prevailing look and feel.</P>
<P ALIGN=CENTER><IMG SRC="Pictures/abfac109.gif">
<A NAME="auto1003"></A>
<P>There is a concrete subclass of WidgetFactory for each look-and-feel
standard. Each subclass implements the operations to create the
appropriate widget for the look and feel. For example, the
CreateScrollBar operation on the MotifWidgetFactory instantiates and
returns a Motif scroll bar, while the corresponding operation on the
PMWidgetFactory returns a scroll bar for Presentation Manager.
Clients create widgets solely through the WidgetFactory interface and
have no knowledge of the classes that implement widgets for a
particular look and feel. In other words, clients only have to commit
to an interface defined by an abstract class, not a particular
concrete class.</P>
<A NAME="auto1004"></A>
<P>A WidgetFactory also enforces dependencies between the concrete widget
classes. A Motif scroll bar should be used with a Motif button and a
Motif text editor, and that constraint is enforced automatically as a
consequence of using a MotifWidgetFactory.</P>
<A NAME="applicability"></A>
<H2><A HREF="#structure"><IMG SRC="gifsb/down3.gif" BORDER=0></A> Applicability</H2>
<A NAME="auto1005"></A>
<P>Use the Abstract Factory pattern when</P>
<UL>
<A NAME="auto1006"></A>
<LI>a system should be independent of how its products are created,
composed, and represented.</LI>
<A NAME="auto1007"></A>
<P></P>
<A NAME="auto1008"></A>
<LI>a system should be configured with one of multiple families of products.
<A NAME="auto1009"></A>
<P></P>
<A NAME="auto1010"></A>
<LI>a family of related product objects is designed to be used
together, and you need to enforce this constraint.
<A NAME="auto1011"></A>
<P></P>
<A NAME="auto1012"></A>
<LI>you want to provide a class library of products, and you want
to reveal just their interfaces, not their implementations.
</UL>
<A NAME="structure"></A>
<H2><A HREF="#participants"><IMG SRC="gifsb/down3.gif" BORDER=0></A> Structure</H2>
<P ALIGN=CENTER><IMG SRC="Pictures/abfac108.gif">
<A NAME="participants"></A>
<H2><A HREF="#collaborations"><IMG SRC="gifsb/down3.gif" BORDER=0></A> Participants</H2>
<UL>
<A NAME="auto1013"></A>
<LI><B>AbstractFactory</B> (WidgetFactory)</LI>
<A NAME="auto1014"></A>
<P></P>
<UL>
<A NAME="auto1015"></A>
<LI>declares an interface for operations that create abstract product
objects.</LI>
</UL>
<A NAME="auto1016"></A>
<P></P>
<A NAME="auto1017"></A>
<LI><B>ConcreteFactory</B> (MotifWidgetFactory, PMWidgetFactory)</LI>
<A NAME="auto1018"></A>
<P></P>
<UL>
<A NAME="auto1019"></A>
<LI>implements the operations to create concrete product objects.</LI>
</UL>
<A NAME="auto1020"></A>
<P></P>
<A NAME="auto1021"></A>
<LI><B>AbstractProduct</B> (Window, ScrollBar)</LI>
<A NAME="auto1022"></A>
<P></P>
<UL>
<A NAME="auto1023"></A>
<LI>declares an interface for a type of product object.</LI>
</UL>
<A NAME="auto1024"></A>
<P></P>
<A NAME="auto1025"></A>
<LI><B>ConcreteProduct</B> (MotifWindow, MotifScrollBar)</LI>
<A NAME="auto1026"></A>
<P></P>
<UL>
<A NAME="auto1027"></A>
<LI>defines a product object to be created by the corresponding concrete
factory.</LI>
<A NAME="auto1028"></A>
<P><!-- extra space --></P>
<A NAME="auto1029"></A>
<LI>implements the AbstractProduct interface.</LI>
</UL>
<A NAME="auto1030"></A>
<P></P>
<A NAME="auto1031"></A>
<LI><B>Client</B></LI>
<A NAME="auto1032"></A>
<P></P>
<UL>
<A NAME="auto1033"></A>
<LI>uses only interfaces declared by AbstractFactory and
AbstractProduct classes.</LI>
</UL>
</UL>
<A NAME="collaborations"></A>
<H2><A HREF="#consequences"><IMG SRC="gifsb/down3.gif" BORDER=0></A> Collaborations</H2>
<UL>
<A NAME="auto1034"></A>
<LI>Normally a single instance of a ConcreteFactory class is created at
run-time. This concrete factory creates product objects having a
particular implementation. To create different product objects,
clients should use a different concrete factory.</LI>
<A NAME="auto1035"></A>
<P></P>
<A NAME="auto1036"></A>
<LI>AbstractFactory defers creation of product objects to its ConcreteFactory
subclass.</LI>
</UL>
<A NAME="consequences"></A>
<H2><A HREF="#implementation"><IMG SRC="gifsb/down3.gif" BORDER=0></A> Consequences</H2>
<A NAME="auto1037"></A>
<P>The Abstract Factory pattern has the following benefits and liabilities:</P>
<OL>
<A NAME="auto1038"></A>
<LI><EM>It isolates concrete classes.</EM>
The Abstract Factory pattern helps you control the classes of objects
that an application creates. Because a factory encapsulates the
responsibility and the process of creating product objects, it
isolates clients from implementation classes. Clients manipulate
instances through their abstract interfaces. Product class names are
isolated in the implementation of the concrete factory; they do not
appear in client code.</LI>
<A NAME="auto1039"></A>
<P></P>
<A NAME="prodobj-exchange"></A>
<LI><EM>It makes exchanging product families easy.</EM>
The class of a concrete factory appears only once in an
application—that is, where it's instantiated. This makes it easy to
change the concrete factory an application uses. It can use
different product configurations simply by changing the concrete
factory. Because an abstract factory creates a complete family of
products, the whole product family changes at once. In our user
interface example, we can switch from Motif widgets to Presentation
Manager widgets simply by switching the corresponding factory objects
and recreating the interface.</LI>
<A NAME="auto1040"></A>
<P></P>
<A NAME="auto1041"></A>
<LI><EM>It promotes consistency among products.</EM>
When product objects in a family are designed to work together, it's
important that an application use objects from only one family at a
time. AbstractFactory makes this easy to enforce.</LI>
<A NAME="auto1042"></A>
<P></P>
<A NAME="auto1043"></A>
<LI><EM>Supporting new kinds of products is difficult.</EM>
Extending abstract factories to produce new kinds of Products isn't
easy. That's because the AbstractFactory interface fixes the set of
products that can be created. Supporting new kinds of products
requires extending the factory interface, which involves changing the
AbstractFactory class and all of its subclasses. We discuss one solution
to this problem in the Implementation section.</LI>
</OL>
<A NAME="implementation"></A>
<H2><A HREF="#samplecode"><IMG SRC="gifsb/down3.gif" BORDER=0></A> Implementation</H2>
<A NAME="auto1044"></A>
<P>Here are some useful techniques for implementing the Abstract Factory
pattern.</P>
<OL>
<A NAME="single-absfact"></A>
<LI><EM>Factories as singletons.</EM>
An application typically needs only one instance of a ConcreteFactory
per product family. So it's usually best implemented as a
<A HREF="pat3efs.htm" TARGET="_mainDisplayFrame">Singleton (127)</A>.
<A NAME="auto1045"></A>
<P></P>
<A NAME="prodobj-creat-absfact"></A>
<LI><EM>Creating the products.</EM> AbstractFactory only declares
an <EM>interface</EM> for creating products. It's up to ConcreteProduct
subclasses to actually create them. The most common way to do this
is to define a factory method (see <A HREF="pat3cfs.htm" TARGET="_mainDisplayFrame">Factory Method (107)</A>) for each product. A concrete
factory will specify its products by overriding the factory method
for each. While this implementation is simple, it requires a new
concrete factory subclass for each product family, even if the
product families differ only slightly.
<A NAME="proto-imp-absfact"></A>
<P>If many product families are possible, the concrete factory can
be implemented using the <A HREF="pat3dfs.htm" TARGET="_mainDisplayFrame">Prototype (117)</A>
pattern. The concrete factory is initialized with a prototypical
instance of each product in the family, and it creates a new product
by cloning its prototype. The Prototype-based approach eliminates
the need for a new concrete factory class for each new product
family.</P>
<A NAME="auto1046"></A>
<P>Here's a way to implement a Prototype-based factory in Smalltalk. The
concrete factory stores the prototypes to be cloned in a dictionary
called <CODE>partCatalog</CODE>. The method <CODE>make:</CODE> retrieves the
prototype and clones it:</P>
<A NAME="auto1047"></A>
<PRE>
make: partName
^ (partCatalog at: partName) copy
</PRE>
<A NAME="auto1048"></A>
<P>The concrete factory has a method for adding parts to the catalog.</P>
<A NAME="auto1049"></A>
<PRE>
addPart: partTemplate named: partName
partCatalog at: partName put: partTemplate
</PRE>
<A NAME="auto1050"></A>
<P>Prototypes are added to the factory by identifying them with a symbol:</P>
<A NAME="auto1051"></A>
<PRE>
aFactory addPart: aPrototype named: #ACMEWidget
</PRE>
<A NAME="auto1052"></A>
<P>A variation on the Prototype-based approach is possible in languages
that treat classes as first-class objects (Smalltalk and Objective C,
for example). You can think of a class in these languages as a
degenerate factory that creates only one kind of product. You can
store <EM>classes</EM> inside a concrete factory that create the various
concrete products in variables, much like prototypes. These classes
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
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -