?? pat4c.htm
字號:
<SCRIPT>
function setFocus() {
if ((navigator.appName != "Netscape") && (parseFloat(navigator.appVersion) == 2)) {
return;
} else {
self.focus();
}
}
</SCRIPT><HTML><HEAD><TITLE>Composite</TITLE><SCRIPT>function setFocus() { if ((navigator.appName != "Netscape") && (parseFloat(navigator.appVersion) == 2)) { return; } else { self.focus(); }}</SCRIPT></HEAD><BODY BGCOLOR = #FFFFFF TEXT = #000000
onLoad="setFocus()";onLoad="setFocus()";><A NAME="top"></A><A NAME="Composite"></A><A NAME="intent"></A><H2><A HREF="#motivation"><IMG SRC="gifsb/down3.gif" BORDER=0 ALT="next: Motivation"></A> Intent</H2> <A NAME="auto1000"></A><P>Compose objects into tree structures to represent part-wholehierarchies. Composite lets clients treat individual objects andcompositions of objects uniformly.</P><A NAME="motivation"></A><H2><A HREF="#applicability"><IMG SRC="gifsb/down3.gif" BORDER=0 ALT="next: Applicability"></A> Motivation</H2> <A NAME="auto1001"></A><P>Graphics applications like drawing editors and schematic capturesystems let users build complex diagrams out of simple components.The user can group components to form larger components, which inturn can be grouped to form still larger components. A simpleimplementation could define classes for graphical primitives suchas Text and Lines plus other classes that act as containers forthese primitives.</P><A NAME="recursivecomp-graphics"></A><P>But there's a problem with this approach: Code that uses theseclasses must treat primitive and container objects differently,even if most of the time the user treats them identically. Havingto distinguish these objects makes the application more complex.The Composite pattern describes how to use recursive compositionso that clients don't have to make this distinction.</P><A NAME="picture-163c"></A><P ALIGN=CENTER><IMG SRC="Pictures/compo075.gif"></P><A NAME="auto1002"></A><P>The key to the Composite pattern is an abstract class thatrepresents <EM>both</EM> primitives and their containers. For thegraphics system, this class is Graphic. Graphic declares operationslike Draw that are specific to graphical objects. It also declaresoperations that all composite objects share, such as operationsfor accessing and managing its children.</P><A NAME="auto1003"></A><P>The subclasses Line, Rectangle, and Text (see preceding class diagram)define primitive graphical objects. These classes implement Draw todraw lines, rectangles, and text, respectively. Since primitivegraphics have no child graphics, none of these subclasses implementschild-related operations.</P><A NAME="auto1004"></A><P>The Picture class defines an aggregate of Graphic objects. Pictureimplements Draw to call Draw on its children, and it implementschild-related operations accordingly. Because the Picture interfaceconforms to the Graphic interface, Picture objects can compose otherPictures recursively.</P><A NAME="auto1005"></A><P>The following diagram shows a typical composite object structureof recursively composed Graphic objects:</P><A NAME="picture-164o"></A><P ALIGN=CENTER><IMG SRC="Pictures/compo074.gif"></P><A NAME="applicability"></A><H2><A HREF="#structure"><IMG SRC="gifsb/down3.gif" BORDER=0 ALT="next: Structure"></A> Applicability</H2> <A NAME="auto1006"></A><P>Use the Composite pattern when</P><UL><A NAME="auto1007"></A><LI>you want to represent part-whole hierarchies of objects.<A NAME="auto1008"></A><P></P><A NAME="auto1009"></A><LI>you want clients to be able to ignore the difference betweencompositions of objects and individual objects. Clients will treat allobjects in the composite structure uniformly.</UL><A NAME="structure"></A><H2><A HREF="#participants"><IMG SRC="gifsb/down3.gif" BORDER=0 ALT="next: Participants"></A> Structure</H2> <P ALIGN=CENTER><IMG SRC="Pictures/compo072.gif"></P><A NAME="auto1010"></A><P>A typical Composite object structure might look like this:</P><A NAME="composite-inst"></A><P ALIGN=CENTER><IMG SRC="Pictures/compo073.gif"></P><A NAME="participants"></A><H2><A HREF="#collaborations"><IMG SRC="gifsb/down3.gif" BORDER=0 ALT="next: Collaborations"></A> Participants</H2><UL><A NAME="auto1011"></A><LI><B>Component</B> (Graphic)<A NAME="auto1012"></A><P></P> <UL> <A NAME="auto1013"></A><LI>declares the interface for objects in the composition.</LI> <A NAME="auto1014"></A><P><!-- extra space --></P> <A NAME="auto1015"></A><LI>implements default behavior for the interface common to all classes, as appropriate.</LI> <A NAME="auto1016"></A><P><!-- extra space --></P> <A NAME="auto1017"></A><LI>declares an interface for accessing and managing its child components.</LI> <A NAME="auto1018"></A><P><!-- extra space --></P> <A NAME="auto1019"></A><LI>(optional) defines an interface for accessing a component's parent in the recursive structure, and implements it if that's appropriate.</LI> </UL><A NAME="auto1020"></A><P></P><A NAME="leaf-part-comp"></A><LI><B>Leaf</B> (Rectangle, Line, Text, etc.)<A NAME="auto1021"></A><P></P> <UL> <A NAME="auto1022"></A><LI>represents leaf objects in the composition. A leaf has no children.</LI> <A NAME="auto1023"></A><P><!-- extra space --></P> <A NAME="auto1024"></A><LI>defines behavior for primitive objects in the composition.</LI> </UL><A NAME="auto1025"></A><P></P><A NAME="auto1026"></A><LI><B>Composite</B> (Picture)<A NAME="auto1027"></A><P></P> <UL> <A NAME="auto1028"></A><LI>defines behavior for components having children.</LI> <A NAME="auto1029"></A><P><!-- extra space --></P> <A NAME="auto1030"></A><LI>stores child components.</LI> <A NAME="auto1031"></A><P><!-- extra space --></P> <A NAME="auto1032"></A><LI>implements child-related operations in the Component interface.</LI> </UL><A NAME="auto1033"></A><P></P><A NAME="auto1034"></A><LI><B>Client</B><A NAME="auto1035"></A><P></P> <UL> <A NAME="auto1036"></A><LI>manipulates objects in the composition through the Component interface.</LI> </UL></UL><A NAME="collaborations"></A><H2><A HREF="#consequences"><IMG SRC="gifsb/down3.gif" BORDER=0 ALT="next: Consequences"></A> Collaborations</H2><UL><A NAME="auto1037"></A><LI>Clients use the Component class interface to interact with objects inthe composite structure. If the recipient is a Leaf, then the requestis handled directly. If the recipient is a Composite, then it usuallyforwards requests to its child components, possibly performingadditional operations before and/or after forwarding.</LI></UL><A NAME="consequences"></A><H2><A HREF="#implementation"><IMG SRC="gifsb/down3.gif" BORDER=0 ALT="next: Implementation"></A> Consequences</H2> <A NAME="auto1038"></A><P>The Composite pattern</P><UL><A NAME="auto1039"></A><LI>defines class hierarchies consisting of primitive objectsand composite objects. Primitive objects can be composed into morecomplex objects, which in turn can be composed, and so on recursively.Wherever client code expects a primitive object, it can also take acomposite object.</LI><A NAME="auto1040"></A><P></P><A NAME="auto1041"></A><LI>makes the client simple.Clients can treat composite structures and individual objectsuniformly. Clients normally don't know (and shouldn't care) whetherthey're dealing with a leaf or a composite component. This simplifiesclient code, because it avoids having to writetag-and-case-statement-style functions over the classes that definethe composition.</LI><A NAME="auto1042"></A><P></P><A NAME="auto1043"></A><LI>makes it easier to add new kinds of components.Newly defined Composite or Leaf subclasses work automatically withexisting structures and client code. Clients don't have to be changedfor new Component classes.</LI><A NAME="auto1044"></A><P></P><A NAME="auto1045"></A><LI>can make your design overly general.The disadvantage of making it easy to add new components is that itmakes it harder to restrict the components of a composite. Sometimesyou want a composite to have only certain components. WithComposite, you can't rely on the type system to enforce thoseconstraints for you. You'll have to use run-time checks instead.</LI></UL><A NAME="implementation"></A><H2><A HREF="#samplecode"><IMG SRC="gifsb/down3.gif" BORDER=0 ALT="next: Sample Code"></A> Implementation</H2> <A NAME="auto1046"></A><P>There are many issues to consider when implementing the Compositepattern:</P><OL><A NAME="parentref-def-comp"></A><LI><EM>Explicit parent references.</EM>Maintaining references from child components to their parent cansimplify the traversal and management of a composite structure. Theparent reference simplifies moving up the structure and deleting acomponent. Parent references also help support the <A HREF="pat5afs.htm" TARGET="_mainDisplayFrame">Chain of Responsibility (223)</A> pattern.<A NAME="auto1047"></A><P>The usual place to define the parent reference is in the Componentclass. Leaf and Composite classes can inherit the reference and theoperations that manage it.</P><A NAME="auto1048"></A><P>With parent references, it's essential to maintain the invariant thatall children of a composite have as their parent the composite that inturn has them as children. The easiest way to ensure this is tochange a component's parent <EM>only</EM> when it's being added orremoved from a composite. If this can be implemented once in the Addand Remove operations of the Composite class, then it can be inheritedby all the subclasses, and the invariant will be maintainedautomatically.</P></LI><A NAME="auto1049"></A><P></P><A NAME="auto1050"></A><LI><EM>Sharing components.</EM>It's often useful to share components, for example, to reduce storagerequirements. But when a component can have no more than one parent,sharing components becomes difficult.<A NAME="flywt-w-compst"></A><P>A possible solution is for children to store multiple parents. Butthat can lead to ambiguities as a request propagates up the structure.The<A HREF="pat4ffs.htm" TARGET="_mainDisplayFrame">Flyweight (195)</A> pattern shows how to rework adesign to avoid storing parents altogether. It works in cases wherechildren can avoid sending parent requests by externalizing some orall of their state.</P></LI><A NAME="auto1051"></A><P></P><A NAME="auto1052"></A><LI><EM>Maximizing the Component interface.</EM>One of the goals of the Composite pattern is to make clients unawareof the specific Leaf or Composite classes they're using. To attainthis goal, the Component class should define as many common operationsfor Composite and Leaf classes as possible. The Component classusually provides default implementations for these operations, andLeaf and Composite subclasses will override them.<A NAME="auto1053"></A><P>However, this goal will sometimes conflict with the principle of classhierarchy design that says a class should only define operations thatare meaningful to its subclasses. There are many operations thatComponent supports that don't seem to make sense for Leaf classes.How can Component provide a default implementation for them?</P><A NAME="auto1054"></A><P>Sometimes a little creativity shows how an operation that would appearto make sense only for Composites can be implemented for allComponents by moving it to the Component class. For example, theinterface for accessing children is a fundamental part of a Compositeclass but not necessarily Leaf classes. But if we view a Leaf as aComponent that <EM>never</EM> has children, then we can define a defaultoperation for child access in the Component class that never <EM>returns</EM> any children. Leaf classes can use the defaultimplementation, but Composite classes will reimplement it to returntheir children.</P><A NAME="auto1055"></A><P>The child management operations are more troublesome and are discussedin the next item.</P></LI><A NAME="auto1056"></A><P></P><A NAME="auto1057"></A><LI><EM>Declaring the child management operations.</EM>Although the Composite class <EM>implements</EM> the Add and Removeoperations for managing children, an important issue in the Compositepattern is which classes <EM>declare</EM> these operations in theComposite class hierarchy. Should we declare these operations in theComponent and make them meaningful for Leaf classes, or should wedeclare and define them only in Composite and its subclasses?<A NAME="auto1058"></A><P>The decision involves a trade-off between safety and transparency:</P><UL><A NAME="auto1059"></A><LI>Defining the child management interface at the root of the classhierarchy gives you transparency, because you can treat all componentsuniformly. It costs you safety, however, because clients may try todo meaningless things like add and remove objects from leaves.</LI><A NAME="auto1060"></A><P></P><A NAME="auto1061"></A><LI>Defining child management in the Composite class gives you safety,because any attempt to add or remove objects from leaves will becaught at compile-time in a statically typed language like C++. Butyou lose transparency, because leaves and composites have differentinterfaces.</LI></UL><A NAME="auto1062"></A><P>We have emphasized transparency over safety in this pattern. If youopt for safety, then at times you may lose type information and haveto convert a component into a composite. How can you do this withoutresorting to a type-unsafe cast?</P><A NAME="leaf-in-comp"></A><P>One approach is to declare an operation <CODE>Composite*GetComposite()</CODE> in the Component class. Component provides a defaultoperation that returns a null pointer. The Composite class redefinesthis operation to return itself through the <CODE>this</CODE> pointer:</P><A NAME="auto1063"></A><PRE> class Composite; ?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -