?? disc4.htm
字號:
<HTML><HEAD> <TITLE>Discussion fo Structural Patterns</TITLE><SCRIPT>function setFocus() { if ((navigator.appName != "Netscape") && (parseFloat(navigator.appVersion) == 2)) { return; } else { self.focus(); }}</SCRIPT></HEAD><BODY TOPMARGIN = 4 LEFTMARGIN = 4 BGCOLOR = #FFFFFFonLoad="setFocus()";><A NAME="top"></A><A NAME="disc4-1"></A><P>You may have noticed similarities between the structural patterns,especially in their participants and collaborations. This is soprobably because structural patterns rely on the same small set oflanguage mechanisms for structuring code and objects: single andmultiple inheritance for class-based patterns, and object compositionfor object patterns. But the similarities belie the different intentsamong these patterns. In this section we compare and contrast groupsof structural patterns to give you a feel for their relative merits.</P><A NAME="disc4-2"></A><A NAME="versus"></A><H2><A HREF="#compvsdec"><IMG SRC="gifsb/down3.gif" BORDER=0 ALT="next: Composite versus Decorator versus Proxy"></A> Adapter versus Bridge</H2><A NAME="disc4-3"></A><P>The<A HREF="pat4afs.htm" TARGET="_mainDisplayFrame">Adapter (139)</A> and<A HREF="pat4bfs.htm" TARGET="_mainDisplayFrame">Bridge (151)</A> patternshave some common attributes. Both promote flexibility by providing alevel of indirection to another object. Both involve forwardingrequests to this object from an interface other than its own.</P><A NAME="disc4-4"></A><P>The key difference between these patterns lies in their intents.Adapter focuses on resolving incompatibilities between two existinginterfaces. It doesn't focus on how those interfaces are implemented,nor does it consider how they might evolve independently. It's a wayof making two independently designed classes work together withoutreimplementing one or the other. Bridge, on the other hand, bridges anabstraction and its (potentially numerous) implementations. Itprovides a stable interface to clients even as it lets you vary theclasses that implement it. It also accommodates new implementations asthe system evolves.</P><A NAME="disc4-5"></A><P>As a result of these differences, Adapter and Bridge are often used atdifferent points in the software lifecycle. An adapter often becomesnecessary when you discover that two incompatible classesshould work together, generally to avoid replicating code. Thecoupling is unforeseen. In contrast, the user of a bridge understandsup-front that an abstraction must have several implementations, andboth may evolve independently. The Adapter pattern makes things work<EM>after</EM> they're designed; Bridge makes them work <EM>before</EM> theyare. That doesn't mean Adapter is somehow inferior to Bridge; eachpattern merely addresses a different problem.</P><A NAME="disc4-6"></A><P>You might think of a facade (see<A HREF="pat4efs.htm" TARGET="_mainDisplayFrame">Facade (185)</A>) as anadapter to a set of other objects. But that interpretation overlooksthe fact that a facade defines a <EM>new</EM> interface, whereas an adapterreuses an old interface. Remember that an adapter makes two <EM>existing</EM> interfaces work together as opposed to defining an entirelynew one.</P><A NAME="disc4-6"></A><A NAME="compvsdec"></A><H2><A HREF="#last"><IMG SRC="gifsb/down3.gif" BORDER=0 ALT="next: navigation"></A>Composite versus Decorator versus Proxy</H2><A NAME="disc4-7"></A><P><A HREF="pat4cfs.htm" TARGET="_mainDisplayFrame">Composite (163)</A> and<A HREF="pat4dfs.htm" TARGET="_mainDisplayFrame">Decorator (175)</A>have similar structure diagrams, reflecting the fact that both rely onrecursive composition to organize an open-ended number of objects.This commonality might tempt you to think of a decorator object as adegenerate composite, but that misses the point of the Decoratorpattern. The similarity ends at recursive composition, again becauseof differing intents.</P><A NAME="disc4-8"></A><P>Decorator is designed to let you add responsibilities to objectswithout subclassing. It avoids the explosion of subclasses that canarise from trying to cover every combination of responsibilitiesstatically. Composite has a different intent. It focuses onstructuring classes so that many related objects can be treateduniformly, and multiple objects can be treated as one. Its focus isnot on embellishment but on representation.</P><A NAME="disc4-9"></A><P>These intents are distinct but complementary. Consequently, theComposite and Decorator patterns are often used in concert. Both leadto the kind of design in which you can build applications just byplugging objects together without defining any new classes. There willbe an abstract class with some subclasses that are composites, somethat are decorators, and some that implement the fundamental buildingblocks of the system. In this case, both composites and decoratorswill have a common interface. From the point of view of the Decoratorpattern, a composite is a ConcreteComponent. From the point of view ofthe Composite pattern, a decorator is a Leaf. Of course, they don't<EM>have</EM> to be used together and, as we have seen, their intentsare quite different.</P><A NAME="disc4-10"></A><A NAME="proxy-vs-decor"></A><P>Another pattern with a structure similar to Decorator's is<A HREF="pat4gfs.htm" TARGET="_mainDisplayFrame">Proxy (207)</A>.Both patterns describe how to provide a level of indirection to anobject, and the implementations of both the proxy and decoratorobject keep a reference to another object to which they forwardrequests. Once again, however, they are intended for differentpurposes.</P><A NAME="disc4-11"></A><P>Like Decorator, the Proxy pattern composes an object and provides anidentical interface to clients. Unlike Decorator, the Proxy pattern isnot concerned with attaching or detaching properties dynamically, andit's not designed for recursive composition. Its intent is to providea stand-in for a subject when it's inconvenient or undesirable toaccess the subject directly because, for example, it lives on a remotemachine, has restricted access, or is persistent.</P><A NAME="disc4-12"></A><P>In the Proxy pattern, the subject defines the key functionality, andthe proxy provides (or refuses) access to it. In Decorator, thecomponent provides only part of the functionality, and one or moredecorators furnish the rest. Decorator addresses the situation wherean object's total functionality can't be determined at compile time,at least not conveniently. That open-endedness makes recursivecomposition an essential part of Decorator. That isn't the case inProxy, because Proxy focuses on one relationship—between the proxyand its subject—and that relationship can be expressed statically.</P><A NAME="disc4-13"></A><P>These differences are significant because they capture solutions tospecific recurring problems in object-oriented design. But thatdoesn't mean these patterns can't be combined. You might envision aproxy-decorator that adds functionality to a proxy, or adecorator-proxy that embellishes a remote object. Although such hybrids<EM>might</EM> be useful (we don't have real examples handy), they aredivisible into patterns that <EM>are</EM> useful.</P><A NAME="disc4-14"></A><A NAME="last"></A><P><A HREF="#top"><IMG SRC="gifsb/up3.gif" BORDER=0></A><BR><A HREF="chap5fs.htm" TARGET="_mainDisplayFrame"><IMG SRC="gifsb/rightar3.gif" ALIGN=TOP BORDER=0></A> <A HREF="chap5fs.htm" TARGET="_mainDisplayFrame">Behavioral Patterns</A><BR><A HREF="pat4gfs.htm" TARGET="_mainDisplayFrame"><IMG SRC="gifsb/leftarr3.gif" ALIGN=TOP BORDER=0></A> <A HREF="pat4gfs.htm" TARGET="_mainDisplayFrame">Proxy</A><BR></P></BODY></HTML>?? 快捷鍵說明
復(fù)制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -