📄 pat4a-1.htm
字号:
<SCRIPT>
function setFocus() {
if ((navigator.appName != "Netscape") && (parseFloat(navigator.appVersion) == 2)) {
return;
} else {
self.focus();
}
}
</SCRIPT><HTML>
<HEAD><TITLE>Adapter</TITLE></HEAD>
<BODY BGCOLOR = #FFFFFF
TEXT = #000000
onLoad="setFocus()";
>
<A NAME="top"></A>
<A NAME="Adapter"></A>
<A NAME="intent"></A>
<H2><A HREF="#alsoknownas"><IMG SRC="down3-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/gifsb/down3.gif" BORDER=0 ALT="next:
Also Known As"></A> Intent</H2>
<A NAME="auto1000"></A>
<P>Convert the interface of a class into another interface clients
expect. Adapter lets classes work together that couldn't otherwise
because of incompatible interfaces.</P>
<A NAME="alsoknownas"><A>
<H2><A HREF="#motivation"><IMG SRC="down3-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/gifsb/down3.gif" BORDER=0 ALT="next:
Motivation"></A> Also Known As</H2>
<A NAME="auto1001"></A>
<P>Wrapper</P>
<A NAME="motivation"></A>
<H2><A HREF="#applicability"><IMG SRC="down3-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/gifsb/down3.gif" BORDER=0
ALT="next: Applicability"></A> Motivation</H2>
<A NAME="auto1002"></A>
<P>Sometimes a toolkit class that's designed for reuse isn't reusable
only because its interface doesn't match the domain-specific interface
an application requires.</P>
<A NAME="auto1003"></A>
<P>Consider for example a drawing editor that lets users draw and arrange
graphical elements (lines, polygons, text, etc.) into pictures and
diagrams. The drawing editor's key abstraction is the graphical
object, which has an editable shape and can draw itself. The
interface for graphical objects is defined by an abstract class called
Shape. The editor defines a subclass of Shape for each kind of
graphical object: a LineShape class for lines, a PolygonShape class
for polygons, and so forth.</P>
<A NAME="textshape"></A>
<A NAME="textview"></A>
<P>Classes for elementary geometric shapes like LineShape and
PolygonShape are rather easy to implement, because their drawing and
editing capabilities are inherently limited. But a TextShape subclass
that can display and edit text is considerably more difficult to
implement, since even basic text editing involves complicated screen
update and buffer management. Meanwhile, an off-the-shelf user
interface toolkit might already provide a sophisticated TextView class
for displaying and editing text. Ideally we'd like to reuse TextView
to implement TextShape, but the toolkit wasn't designed with Shape
classes in mind. So we can't use TextView and Shape objects
interchangeably.</P>
<A NAME="auto1004"></A>
<P>How can existing and unrelated classes like TextView work in an
application that expects classes with a different and incompatible
interface? We could change the TextView class so that it conforms to
the Shape interface, but that isn't an option unless we have the
toolkit's source code. Even if we did, it wouldn't make sense to
change TextView; the toolkit shouldn't have to adopt domain-specific
interfaces just to make one application work.</P>
<A NAME="adapterdef"></A>
<P>Instead, we could define TextShape so that it <EM>adapts</EM> the
TextView interface to Shape's. We can do this in one of two ways: (1)
by inheriting Shape's interface and TextView's implementation or (2)
by composing a TextView instance within a TextShape and implementing
TextShape in terms of TextView's interface. These two approaches
correspond to the class and object versions of the Adapter pattern.
We call TextShape an <STRONG>adapter</STRONG>.</P>
<A NAME="shape-140c"></A>
<P ALIGN=CENTER><IMG SRC="adapt105-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/Pictures/adapt105.gif"></P>
<A NAME="auto1005"></A>
<P>This diagram illustrates the object adapter case. It shows how
BoundingBox requests, declared in class Shape, are converted to
GetExtent requests defined in TextView. Since TextShape adapts
TextView to the Shape interface, the drawing editor can reuse the
otherwise incompatible TextView class.</P>
<A NAME="auto1006"></A>
<P>Often the adapter is responsible for functionality the adapted class
doesn't provide. The diagram shows how an adapter can fulfill
such responsibilities. The user should be able to "drag" every
Shape object to a new location interactively, but TextView isn't
designed to do that. TextShape can add this missing functionality by
implementing Shape's CreateManipulator operation, which returns an
instance of the appropriate Manipulator subclass.</P>
<A NAME="auto1007"></A>
<P>Manipulator is an abstract class for objects that know how to animate
a Shape in response to user input, like dragging the shape to a new
location. There are subclasses of Manipulator for different shapes;
TextManipulator, for example, is the corresponding subclass for
TextShape. By returning a TextManipulator instance, TextShape adds
the functionality that TextView lacks but Shape requires.</P>
<A NAME="applicability"></A>
<H2><A HREF="#structure"><IMG SRC="down3-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/gifsb/down3.gif" BORDER=0 ALT="next:
Structure"></A> Applicability</H2>
<A NAME="auto1008"></A>
<P>Use the Adapter pattern when</P>
<UL>
<A NAME="auto1009"></A>
<LI>you want to use an existing class, and its interface does not
match the one you need.</P>
<A NAME="auto1010"></A>
<LI>you want to create a reusable class that cooperates with unrelated or
unforeseen classes, that is, classes that don't necessarily have
compatible interfaces.</P>
<A NAME="auto1011"></A>
<LI><EM>(object adapter only)</EM>
you need to use several existing subclasses, but it's impractical to
adapt their interface by subclassing every one. An object adapter can
adapt the interface of its parent class.</P>
</UL>
<A NAME="structure"></A>
<H2><A HREF="#participants"><IMG SRC="down3-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/gifsb/down3.gif" BORDER=0
ALT="next: Participants"></A> Structure</H2>
<A NAME="141c"></A>
<P>A class adapter uses multiple inheritance to adapt one interface
to another:</P>
<P ALIGN=CENTER><IMG SRC="adapt106-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/Pictures/adapt106.gif"></P>
<A NAME="141o"></A>
<P>An object adapter relies on object composition:</P>
<P ALIGN=CENTER><IMG SRC="adapt104-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/Pictures/adapt104.gif"></P>
<A NAME="participants"></A>
<H2><A HREF="#collaborations"><IMG SRC="down3-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/gifsb/down3.gif" BORDER=0
ALT="next: Collaborations"></A> Participants</H2>
<UL>
<A NAME="auto1012"></A>
<LI><B>Target</B> (Shape)
<A NAME="auto1013"></A>
<P></P>
<UL>
<A NAME="auto1014"></A>
<LI>defines the domain-specific interface that Client uses.</LI>
</UL>
<A NAME="auto1015"></A>
<P></P>
<A NAME="auto1016"></A>
<LI><B>Client</B> (DrawingEditor)
<A NAME="auto1017"></A>
<P></P>
<UL>
<A NAME="auto1018"></A>
<LI>collaborates with objects conforming to the Target interface.</LI>
</UL>
<A NAME="auto1019"></A>
<P></P>
<A NAME="auto1020"></A>
<LI><B>Adaptee</B> (TextView)
<A NAME="auto1021"></A>
<P></P>
<UL>
<A NAME="auto1022"></A>
<LI>defines an existing interface that needs adapting.</LI>
</UL>
<A NAME="auto1023"></A>
<P></P>
<A NAME="auto1024"></A>
<LI><B>Adapter</B> (TextShape)
<A NAME="auto1025"></A>
<P></P>
<UL>
<A NAME="auto1026"></A>
<LI>adapts the interface of Adaptee to the Target interface.</LI>
</UL>
</UL>
<A NAME="collaborations"></A>
<H2><A HREF="#consequences"><IMG SRC="down3-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/gifsb/down3.gif" BORDER=0
ALT="next: Consequences"></A> Collaborations</H2>
<UL>
<A NAME="auto1027"></A>
<LI>Clients call operations on an Adapter instance. In turn, the adapter
calls Adaptee operations that carry out the request.</LI>
</UL>
<A NAME="consequences"></A>
<H2><A HREF="#implementation"><IMG SRC="down3-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/gifsb/down3.gif" BORDER=0
ALT="next: Implementation"></A> Consequences</H2>
<A NAME="auto1028"></A>
<P>Class and object adapters have different trade-offs. A class adapter</P>
<UL>
<A NAME="auto1029"></A>
<LI>adapts Adaptee to Target by committing to a concrete Adaptee class.
As a consequence, a class adapter won't work when we want to adapt a
class <EM>and</EM> all its subclasses.</LI>
<A NAME="auto1030"></A>
<P></P>
<A NAME="auto1031"></A>
<LI>lets Adapter override some of Adaptee's behavior, since
Adapter is a subclass of Adaptee.</LI>
<A NAME="auto1032"></A>
<P></P>
<A NAME="auto1033"></A>
<LI>introduces only one object, and no additional pointer indirection is
needed to get to the adaptee.</LI>
</UL>
<A NAME="auto1034"></A>
<P>An object adapter</P>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -