適配器模式

概述

?

這一章我們通過(guò)對(duì)適配器模式 (Adapter Pattern) 的講解來(lái)繼續(xù)我們對(duì)設(shè)計(jì)模式的學(xué)習(xí)。 Adapter 模式是一個(gè)經(jīng)常使用的模式，正如你將會(huì)看到的那樣，她常和其他模式一起使用。

在這一章里：

l????????? 我們將學(xué)習(xí)到什么是 Adapter 模式，她有什么用，以及怎么用。

l????????? 在章末的時(shí)候?qū)?huì)有 Adapter 模式的主要功能的總結(jié)。

l????????? 通過(guò) Adapter 模式演示多態(tài)的使用。

l????????? 演示用 UML 圖來(lái)表示不同層次的細(xì)節(jié)描述。

l????????? 我在實(shí)踐過(guò)程中的一些對(duì) Adapter 模式的觀察和思考，還會(huì)將 Adapter 模式和 Facade 模式進(jìn)行對(duì)比。

l????????? ?

Adapter 模式簡(jiǎn)介

?

在 GoF 的經(jīng)典著作《設(shè)計(jì)模式》中指出： Adapter 模式的目的就是將類的接口轉(zhuǎn)換成客戶對(duì)象需要的接口， Adapter 模式使原本不相容的接口變的相容。也就是說(shuō)我們有一個(gè)可以滿足我們需要的對(duì)象，但是她的接口卻不是象我們所期望的那樣，而我們現(xiàn)在所需要的就是創(chuàng)建一個(gè)新的接口，讓原本的接口能夠滿足我們的需要。

?

Adapter 模式詳解

?

要理解 Adapter 模式最簡(jiǎn)單的方式就是看看她實(shí)際應(yīng)用的一個(gè)例子。假設(shè)有如下的要求：

l????????? 創(chuàng)建一些代表著 點(diǎn)、線、方形 的類，并包含“ display ” ( 顯示 ) 這個(gè)方法 / 行為。

l????????? 客戶對(duì)象不需要知道正在使用的對(duì)象是 點(diǎn)、線 還是方形，只需要知道是一種形狀 (shape) 就可以了。

換句話說(shuō)，我需要把這些確切的點(diǎn)啦、線啦、方形啦等等用更概念性的語(yǔ)言類概括起來(lái)，也就是 顯示一個(gè)形狀。

當(dāng)我們?cè)谕瓿蛇@個(gè)例子的時(shí)候，我們可能會(huì)遇到這樣的情況：

l????????? 我們想用一段子程序或者說(shuō)一些別人已經(jīng)寫好了的代碼，因?yàn)檫@些剛好能夠完成我們所需要的某些功能。

l????????? 但是，我們又不能把這些程序啦、代碼啦直接放到我們自己的程序里面去，

l????????? 因?yàn)檫@些程序、代碼的接口的調(diào)用方式和我們期望的又不一樣。

?

也就是說(shuō)雖然當(dāng)前的系統(tǒng)里有 點(diǎn)、線、方形等等這些對(duì)象，但是，我的程序僅僅需要把他們統(tǒng)統(tǒng)當(dāng)成是一種形狀這就足夠了。具體是點(diǎn)、線、還是方形，我不感興趣。

l????????? 這可以使得我的程序可以用一種方式來(lái)處理所有的“形狀”，這樣，就不必再去考慮這個(gè) 點(diǎn) 和 線 他們有什么不同之類的問(wèn)題。

l????????? 這種方式還可以讓我以后可以在不改變現(xiàn)有的使用方式的情況下添加進(jìn)新的具體形狀。

?

這樣，我們就需要用到 多態(tài) (polymorphism) 。就是說(shuō)，我的系統(tǒng)里會(huì)有各種各樣的具體形狀，但是我可以用一個(gè)通用的方式來(lái)操縱這些所有的形狀。

這樣，客戶對(duì)象就可以簡(jiǎn)單地告訴這些 點(diǎn)、線 讓他們?cè)谄聊簧巷@示出來(lái)，或者從屏幕上消失。這些 點(diǎn)、線 他們自己會(huì)知道自己該怎么樣的去顯示或不顯示，不需要客戶對(duì)象去考慮這個(gè)問(wèn)題。

?

要達(dá)到這點(diǎn)，我們先創(chuàng)建一個(gè) Shape 類，然后從她派生 (derive) 出一些代表著 點(diǎn)、線 等具體形狀的類。請(qǐng)參看圖 7-2 。

?

圖 7-2 Point 、 Lines 、和 Square 都是一種具體的 Shape 。

?

首先，我們必須給 Shape 類確定一些她將會(huì)提供的具體行為。我們可以通過(guò)在 Shape 里面定義一些抽象接口然后在 Point Line Square 等類中具體實(shí)現(xiàn)這些接口的方式來(lái)達(dá)到目的。

我們給 Shape 提供以下的一些方法：

l????????? 指定 Shape 在屏幕上的位置

l????????? 獲取 Shape 在屏幕上的位置

l????????? 讓 Shape 在屏幕上顯示

l????????? 對(duì) Shape 進(jìn)行填充

l????????? 給 Shape 指定一個(gè)顏色

l????????? 讓 Shape 從屏幕上消失

?

?

假設(shè)現(xiàn)在我們又被要求要去實(shí)現(xiàn)一個(gè) 圓 ? 一個(gè)新的形狀 ( 要知道，客戶對(duì)我們的要求總是在不停的變來(lái)變?nèi)サ?/span> ) 。這樣，我們就又要?jiǎng)?chuàng)建一個(gè)新的 Circle 類了。我們讓 Circle 也繼承 Shape ，這樣我們就也可以對(duì) Circle 使用多態(tài)，讓他向上轉(zhuǎn)型 (upcasting) 到 Shape 了。 Circle 類是建立好了，但是我們現(xiàn)在就需要對(duì)她的 display() fill() undisplay() 等等這些方法編碼了。這好像是一個(gè)痛苦的事情。

幸運(yùn)的是，幾經(jīng)搜索 ( 就像優(yōu)秀的編碼人員經(jīng)常做的那樣 ) ，我終于找到一個(gè)替代品 (alternative) 了。我發(fā)現(xiàn) Jill 同學(xué)已經(jīng)寫了一個(gè)名為 XXCircle 的類來(lái)處理和圓相關(guān)的東西 ( 如圖 7-4) 。然而，很不幸的是， Jill 并沒(méi)有象我們這樣定義 XXCircle 里的方法。她定義成了： displayIt() 、 fillIt() 、 undisplayIt() 。

?

圖 7-4 Jill 的 XXCircle 類

?

由于我們還要用 Shape 的多態(tài)，所以我們不可能直接用 Jill 的 XXCircle 類。至于為什么，那是因?yàn)椋?/span>

l????????? 不同的方法名稱和參數(shù)表 ? XXCircle 里的方法名稱和參數(shù)表和我們的 Shape 類的完全不一樣。

l????????? 不是 Shape 的派生類 ( 子類 )? 我們不僅僅要求方法名稱參數(shù)表要一樣還要求繼承 Shape 類。

?

也許我們可以試著讓 Jill 同學(xué)按照我們的需要來(lái)重寫她的 XXCircle ，改變方法名稱和參數(shù)表并且繼承 Shape 類。但是，這肯定是不現(xiàn)實(shí)的。因?yàn)椋绻貙懥?/span> XXCircle ，那么 Jill 以前用到 XXCircle 的地方也都要完全重寫，而且，修改正在使用中的代碼有可能會(huì)產(chǎn)生難以預(yù)知的副作用。

?

看起來(lái)我們就要達(dá)到目的了，然而卻不能用，而我又懶得自己老老實(shí)實(shí)去寫，怎么辦呢？

?

( 不是有句話說(shuō)：“既然不能改變它，就去適應(yīng)它么”？……譯著 )

?

與其改變 XXCircle ，倒不如適配它。

?

我可以從 Shape 派生一個(gè)類，這樣，這個(gè)類就可以實(shí)現(xiàn) Shape 的所有接口而避免重寫 XXCircle 。具體情況請(qǐng)看圖 7-5 。

?

圖 7-5 Adapter 模式： Circle 包含 XXCircle

l????????? Circle 類繼承自 Shape 。

l????????? Circle 里包含了 XXCircle 。

l????????? Circle 把所有傳遞給 Circle 類型對(duì)象的請(qǐng)求全部傳遞給 XXCircle 類的對(duì)象。

圖 7-5 中 Circle 和 XXCircle 中連線末端的菱形表明 Circle 包含得有 XXCircle 。當(dāng) Circle 類的對(duì)象初始化的時(shí)候，該對(duì)象會(huì)同時(shí)初始化一個(gè)相關(guān)的 XXCircle 類的對(duì)象。如果 XXCircle 對(duì)象包含有 Circle 所需要的所有功能，那么對(duì) Circle 對(duì)象的任何操作都將被傳遞到 XXCircle 上去執(zhí)行完成 (XXCircle 不包含所有 Circle 需要功能的情況隨后再說(shuō) ) 。

?

通過(guò) Adapter 我們就可以繼續(xù)對(duì) Shape 使用多態(tài)了。就是說(shuō)，客戶對(duì)象并不需要知道 Shape 對(duì)象所代表的確切類型。這也是一種新的封裝思想。 Shape 類封裝了形狀的確切類型。 Adapter 應(yīng)用得最多的目的就是使我們能夠有機(jī)會(huì)使用多態(tài)。在隨后的章節(jié)中你就會(huì)發(fā)現(xiàn)其他很多模式都要求用到多態(tài)。

?

?

?

我們通常都會(huì)遇到和前面例子相似的情況，但是有時(shí)，被適配的對(duì)象并不一定能完全滿足我們的需要。

?

在這樣的情況下，我們?nèi)匀豢梢杂玫?/span> Adapter 模式，但似乎不如先前的那么完美了。在這樣的一個(gè)情況下：

l????????? 在既存在的類中已經(jīng)實(shí)現(xiàn)的功能可以被我們適配。

l????????? 那些我們需要但又不在既存在類中的方法，我們可以在適配器類中去實(shí)現(xiàn)。

?

雖然這樣并不如先前例子中的那么好，但是，至少，我們只需要再去實(shí)現(xiàn)一部分功能就可以了。

?

Adapter 模式使我在設(shè)計(jì)過(guò)程中不再為那些已經(jīng)存在的接口所煩惱。如果一個(gè)類可以完成我的工作，那么至少?gòu)睦碚撋现v，我完全可以通過(guò) Adapter 模式來(lái)得到適當(dāng)?shù)慕涌凇?/span>

?

當(dāng)你學(xué)習(xí)了更多的模式以后，你會(huì)越發(fā)發(fā)現(xiàn) Adapter 的重要性。很多模式都要求某些類都繼承自同一個(gè)類。如果有既存在的類， Adapter 模式就可以用來(lái)將該類適配給恰當(dāng)?shù)某橄箢?/span> ( 就象 Circle 把 XXCircle 適配給 Shape 那樣 ) 。

?

通過(guò)我們講到的這么些類，總有人會(huì)認(rèn)為好像 Adapter 模式和 Facade 模式是一回事。他們都有既存在的類，都沒(méi)有恰當(dāng)?shù)慕涌冢覀兌紕?chuàng)建了包含恰當(dāng)接口的新對(duì)象。

?

圖 7-6 客戶對(duì)象 使用 既存在 但擁有不恰當(dāng)接口 的對(duì)象

我們常聽(tīng)到 包裝 和 對(duì)對(duì)象進(jìn)行包裝 的說(shuō)法。現(xiàn)在很流行對(duì)包裝遺留系統(tǒng) (wrapping legacy system) 和使對(duì)象變的簡(jiǎn)單可用的思考。

?

從這個(gè)高度來(lái)說(shuō)， Facade 和 Adapter 的確有點(diǎn)相似，他們都是進(jìn)行 包裝 。但他們是不同類型的包裝方式。你應(yīng)該明白這其中的小小不同。找到并理解到這其中的不同將給我們一個(gè)對(duì)模式的性質(zhì)的新視角，在討論一個(gè)設(shè)計(jì)或者給設(shè)計(jì)寫文檔以使別人知道對(duì)象的確切用途的時(shí)候，這些都非常有用。讓我們來(lái)看看 Facade 和 Adapter 有何不同。

?

從上面的表里面可以看出：

l????????? Facade 和 Adapter 都有預(yù)先存在的類。

l????????? Facade 并不象 Adapter 那樣有必須實(shí)現(xiàn)的接口。

l????????? Facade 模式下我并不對(duì)多態(tài)感興趣，而 Adapter 模式有時(shí)要用到多態(tài)。 ( 有時(shí)，我們僅僅是因?yàn)樾枰獙?shí)現(xiàn)某個(gè)特定接口而使用 Adapter ，這時(shí)，多態(tài)就無(wú)關(guān)緊要了。 )

l????????? Facade 模式的目的是簡(jiǎn)化接口。 Adapter 模式下，雖然是越簡(jiǎn)單越好，但我們是根據(jù)一個(gè)既存在的類進(jìn)行設(shè)計(jì)，我們不能簡(jiǎn)化它。

?

總之 ， Facade 簡(jiǎn)化接口， Adapter 把一個(gè)已經(jīng)存在的接口轉(zhuǎn)化成另一接口。

?

總結(jié)

?

Adapter 模式是一個(gè)經(jīng)常使用的模式，她可以將已經(jīng)存在的接口按照我們的需要進(jìn)行轉(zhuǎn)換。 Adapter 模式通過(guò)創(chuàng)建一個(gè)包含有需要的接口的類，并把被適配的對(duì)象包含到新類當(dāng)中的方式來(lái)實(shí)現(xiàn)。

?




========================原文================原文==============原文=============================

The Adapter Pattern

?

Overview

I will continue our study of design patterns with the Adapter pattern. The Adapter pattern is a very common pattern, and, as you will see, it is used with many other patterns.

?

This chapter

l ???????? Explains what the Adapter pattern is, where it is used, and how it is implemented.

l ???????? Presents the key features of the pattern.

l ???????? Uses the pattern to illustrate polymorphism.

l ???????? Illustrates how the UML can be used at different levels of detail.

l ???????? Presents some observations on the Adapter pattern from my own practice, including a comparison of the Adapter pattern and the Facade pattern.

l ???????? Relates the Adapter pattern to the CAD/CAM problem.

?

Introducing the Adapter pattern

According to the Gang of Four, the intent of the Adapter pattern is to

Convert the interface of a class into another interface that the clients expect. Adapter lets classes work together that could not otherwise because of incompatible interfaces.

Basically, this is saying that we need a way to create a new interface for an object that does the right stuff but has the wrong interface.

?

Learning the Adapter Pattern

The easiest way to understand the intent of the Adapter pattern is to look at an example of where it is useful. Let’s say I have been given the following requirements:

l ???????? Create classes for points, lines, and squares that have the behavior “display”.

l ???????? The client objects should not have to know whether they actually have a point, a line, or a square. They just want to know that they have one of these shapes.

?

In other words, I want to encompass these specific shapes in a higher-level concept that I will call a “displayable shape”.

?

Now, as I work through this simple example, try to imagine other situations that you have run into that are similar, such as the following:

l ???????? You have wanted to use a subroutine or a method that someone else has written because it performs some function that you need.

l ???????? You cannot incorporate the routine directly into your program.

l ???????? The interface or the way of calling the code is not exactly equivalent to the way that its related objects need to use it.

In other words, although the system will have points, lines, and squares, I want the client objects to think I have only shapes.

l ???????? This allows client objects to deal with all these objects in the same way － freed from having to pay attention to their differences.

l ???????? It also enables me to add different kinds of shapes in the future without having to change the clients.

I will make use of polymorphism; that is, I will have different objects in my system, but I want the clients of these objects to interact with them in a common way.

?

In this case, the client object will simply tell a point, line, or square to do something such as display itself or undisplay itself. Each point, line, and square is then responsible for knowing the way to carry out the behavior that is appropriate to its type.

?

To accomplish this, I will create a Shape class and then derive from it the classes that represent points, lines, and squares (see Figure 7-2).

?

Figure 7-2? Points, Lines, and Squares are types of Shape

First I must specify the particular behavior that Shapes are going to provide. To accomplish this, I define an interface in the Shape class and then implement the behavior appropriately in each of the derived classes.

?

The behaviors that a Shape needs to have are as follows:

l ???????? Set a Shape’s location.

l ???????? Get a Shape’s location.

l ???????? Display a Shape.

l ???????? Fill a Shape.

l ???????? Set the color of a Shape.

l ???????? Undisplay a Shape.

I show these in Figure 7-3.

?

Figure 7-3? Points, Lines, and Squares showing methods.

Suppose I am now asked to implement a circle, a new kind of Shape. (Remember, requirements always change!) To do this, I will want to create a new class － Circle － that implements the shape “circle” and derive it from the Shape class so that I can still get polymorphic behavior.

Now I am faced with the task of having to code the display, fill and undisplay methods for Circle. That could be a pain.

?

Fortunately, as I scout around for an alternative (as a good coder always should), I discover that Jill down the hall has already written a class she called XXCircle that already handles circles (see Figure 7-4). Unfortunately, she didn’t ask me what she should name the methods. She named the methods as follows:

l ???????? displayIt

l ???????? fillIt

l ???????? undisplayIt

?

Figure 7-4? Jill’s XXCircle class.

I cannot use XXCircle directly because I want to preserve polymorphic behavior with Shape. There are two reasons for this:

l ???????? I have different names and parameter lists － The method names and parameter lists are different from Shape’s method names and parameter list.

l ???????? I cannot derive it － Not only must the names be the same, but the class must be derived from Shape as well.

It is unlikely that Jill will be willing to let me change the names of her methods or derive XXCircle from Shape. To do so would require her to modify all the other objects that are currently using XXCircle. Plus, I would still be concerned about creating unanticipated side effects when I modify someone else’s code.

I have what I want almost within reach, but I cannot use it and I don’t want to rewrite it. What can I do?

?

Rather than change it, I adapt it.

?

I can make a new class that does derive from Shape and therefore implements Shape’s interface but avoids rewriting the circle implementation in XXCircle (see Figure 7-5):

?

Figure 7-5 The Adapter pattern: Circle “wraps” XXCircle.

l ???????? Class Circle derives from Shape.

l ???????? Circle contains XXCircle.

l ???????? Circle passes request made to the Circle object through to the XXCircle object.

?

The diamond at the end of the line between Circle and XXCircle in Figure 7-5 indicates that Circle contains an XXCircle. When a Circle object is instantiated, it must instantiate a corresponding XXCircle object. Anything the Circle object is told to do will get passed to the XXCircle object has the complete functionality the Circle object needs (I discuss soon what happens if this is not the case), the Circle object will be able to manifest its behavior by letting the XXCircle object do the job.

?

An example of wrapping is shown in Example 7-1

?

Class Circle extends Shape {

…

?????? private XXCircle myXXCircle;

…

Public Circle () {

?????? myXXCircle = new XXCircle ();

}

?

public void display () {

?????? myXXCircle.displayIt();

}

…

?

Using the Adapter pattern enabled me to continue using polymorphism with Shape. In other words, the client objects of Shape do not know what types of shapes are actually present. This is also an example of our new thinking about encapsulation as well － the class Shape encapsulates the specific shapes present. The Adapter pattern is most commonly used to allow for polymorphism. As you shall see in later chapters, it is often used to allow for polymorphism required by other design patterns.

?

Fields Notes: The Adapter Pattern

Often I am in a situation similar to the one just described, but the object being adapted does not do all the things I need.

?

In this case, I can still use the Adapter pattern, but it is not such a perfect fit. In such as case

l ???????? Those functions that are implemented in the existing class can be adapted.

l ???????? Those functions that are not present can be implemented in the wrapping class.

?

This does not give me quite the same benefit, but at least I do not have to implement all of the required functionality.

?

The Adapter pattern frees me from worrying about the interfaces of existing classes when I am doing a design. If I have a class that does what I need, at lease conceptually, I know that I can always use the Adapter pattern to give it the correct interface.

?

This will become more important as you learn a few more patterns. Many patterns require certain classes to derive from the same class. If there are preexisting classes, the Adapter pattern can be used to adapt it to the appropriate abstract class (as Circle adapted XXCircle to Shape).

?

There are actually two types of Adapter patterns:

l ???????? Object Adapter pattern － The Adapter pattern I have been using is called an Object Adapter because it relies on one object (the adapting object) containing another (the adapted object).

l ???????? Class Adapter pattern － Another way to implement the Adapter pattern is with multiple inheritance. In this case, it is called a Class Adapter pattern.

?

The Class Adapter works by creating a new class which

l ???????? Derives publicly from our abstract class to define its interface.

l ???????? Derives privately from our existing class to access its implementation.

?

Each wrapped method calls its associated, privately inherited method.

?

The decision of which Adapter pattern to use is based on the different forces at work in the problem domain. At a conceptual level, I may ignore the distinction; however, when it comes time to implement it, I need to consider more of the forces involved.

?

In my classes on design patterns, someone almost always states that it sounds as if both the Adapter pattern and the Facade pattern are the same. In both cases there is a preexisting class (or a class) that does not have the interface that is needed. In both cases, I create a new object that has the desired interface (see Figure 7-6).

?

Figure 7-6 A Client object using another, preexisting object with the wrong interface.

?

Wrappers and object wrappers are terms that you hear a lot about. It is popular to think about wrapping legacy systems with objects to make them easier to use.

?

At this high view, the Facade and the Adapter patterns do seem similar. They are both wrappers. But they are different kinds of wrappers. You need to understand the differences, which can be subtle. Finding and understanding these more subtle differences gives insight into a pattern’s properties. It also helps when discussing and documenting a design so others know precisely what the object(s) are for. Let’s look at some different forces involved with these patterns (see the following table).

?

?

This table tells us the following:

l ???????? With both the Facade and Adapter pattern, I have preexisting classes.

l ???????? With the Facade, however, I do not have an interface I must design to, as I in the Adapter pattern.

l ???????? I am not interested in polymorphic behavior with the Facade; whereas with the Adapter, I probably am. (There are times when we just need to design to a particular interface and therefore must use an Adapter. In this case, polymorphism may not be an issue － that’s way I say “probably”.)

l ???????? In the case of the Facade pattern, the motivation is to simplify the interface. With the Adapter, although simpler is better, I am trying to design to an existing interface and cannot simplify things even if a simpler interface were otherwise possible.

?

Sometimes people draw the conclusion that another difference between the Facade and the Adapter pattern is that the Facade hides multiple classes behind it whereas the Adapter only hides one. Although this is often true, it is not part of the pattern. It is possible that a Facade could be used in front of a very complex object while an Adapter wrapped several objects that among them implemented the desired function.

?

Bottom line : A Facade simplifies an interface while an Adapter converts a preexisting interface into another interface.

?

Summary

?

The Adapter pattern is a frequently used pattern that converts the interface of a class (or classes) into another interface, which we need the class to have. It is implemented by creating a new class with the desired interface and then wrapping the original class methods to effectively contain the adapted object.

?

?