1. Rectangle 的 draw() 方法和先前的一樣 ( 都根據(jù)需要調(diào)用 drawLine() 四次 ) 。

2. drawLine() 通過調(diào)用 DP1 的 draw_a_line() 來實現(xiàn)。

其執(zhí)行的步驟如圖 10-4 所示。

Figure 10-4 Sequence Diagram when have a V1Rectangle.

雖然，在類圖上看起來，程序里有很多的對象，但是實際上，我只需要處理三個對象。如圖 10-5 所示。

Figure 10-5 The Objects present.

1. Client 對象使用到矩形。

2. V1Rectangle 對象。

3. 繪圖程序 DP1 。

當(dāng) client 對象傳遞一個消息到 V1Rectangle 的對象 ( 也就是 myRectangle) ，執(zhí)行其中的 draw() 方法的時候，它通過圖中的步驟 2 到步驟 9 來完成調(diào)用 draw() 方法的全過程。

不幸的是，這種方法又引起了新的問題?；剡^頭來看看圖 10-3 ，仔細(xì)看看第三行的類，想想下面的問題：

1. 這一行的類代表了四種不同類型的 Shape 。

2. 如果我現(xiàn)在又有了一個新的繪圖程序，也就是說，在實現(xiàn)上又有了一個新的變化。這樣，我是不是該有 6 個類了？ (2 個 Shape 再乘上 3 個繪圖程序。 )

3. 再來，如果在前面基礎(chǔ)上，我現(xiàn)在又要實現(xiàn)一個新的形狀，比方說，再來個橢圓，完了，現(xiàn)在，我該有 3 ＊ 3 ＝ 9 個類了。

類的數(shù)量就和滾雪球一樣，越來越多。這種情況的出現(xiàn)是因為抽象 ( 各種各樣的 Shape) 和實現(xiàn) ( 多個繪圖程序 ) 他們很緊密地耦合在一起！每種確切的形狀都要知道它所使用的繪圖程序的具體類型?？礃幼?，要避免這種類在數(shù)量上的爆炸式的增長，我得需要一個能夠把抽象和實現(xiàn)分離看來的方法。讓他們可以獨立的發(fā)生變化。這樣，類的數(shù)量就可以呈現(xiàn)出線性的增長，而不是近指數(shù)形式的增長了。如圖 10-6 所示。

Figure 10-6 The Bridge pattern separate variations in abstraction and implementation.

在具體講解處理方法和 Bridge 模式之前，我還想講點其他的問題。

讓我們再次回過頭去看看圖 10-3 ，自問一下：這個設(shè)計的缺點在哪里？

1. 這個設(shè)計看起來是不是有點累贅？

2. 設(shè)計里的對象間是結(jié)合是否緊密呢？

3. 對象是不是很緊密的耦合在一起呢？

這樣的代碼，你愿意去維護(hù)嗎？

濫用繼承

作為一個新手，我曾經(jīng)趨向于用“特殊化”的方式來解決問題，也就是利用繼承。我曾經(jīng)很喜歡使用繼承這種方式，因為它是個新穎有功能強(qiáng)大的方法。我總是盡可能地使用繼承，這樣的情況在新手里經(jīng)常出現(xiàn)，但是，這種做法是很天真的：有了“繼承”這把“榔頭”，見到啥玩意都象顆釘子，一榔頭就下去了。然而，令人感到遺憾的是，在學(xué)習(xí)面向?qū)ο笤O(shè)計的過程中，人們總是受著“特殊化”的熏陶，總是被教導(dǎo)著通過特殊化來處理一切變化，無休止的從基類派生出新類。由于過度地注重“是什么”，而使得很多設(shè)計都是建立在一些很固化的繼承鏈上的，這些設(shè)計在一開始的時候可以很好的運行，但是，隨著時間的推移，這些設(shè)計將會變得非常難以維護(hù) ( 正如在第九章，”策略模式”里面所講到的那樣 ) 。 即使是在我經(jīng)驗已經(jīng)比較豐富的時候，我還是會把這種基于繼承的方法過度的應(yīng)用到設(shè)計當(dāng)中，只管類”是什么”，而并沒有意識到我這么做，將會使整個設(shè)計在結(jié)構(gòu)上變得多么的復(fù)雜！ 而，是設(shè)計模式的思維方法使我擺脫了這些。我學(xué)會用我的對象具有什么要嗯的職能的方式去思考問題，而不再是單從對象的結(jié)構(gòu)上去思考問題。 真正有經(jīng)驗的面向?qū)ο蟮脑O(shè)計師，他們都會很有選擇性地使用繼承。而學(xué)習(xí)設(shè)計模式，將會使你更快的學(xué)到這些。它將帶給你一個從把每個變體特殊化到學(xué)會使用聚合的轉(zhuǎn)變。

最初，我看到這些問題的出現(xiàn)，我曾以為這一切都是因為我的繼承方式使用得不對而引起的。于是，我試著改進(jìn)了先前的繼承鏈，把它變得像圖 10-7 那樣。

Figure 10-7 An alternative implementation.

我還是有四個類，但是，通過首先就按繪圖程序的不同而區(qū)分類的方式，減少了很多 DP1 和 DP2 之間的冗余內(nèi)容。

然而，我還是不能排除兩種 Rectangle 和兩種 Circle 之間的冗余，每種 Rectangle 和每種的 Circle 都有相同的 draw() 方法。

不管怎么說，先前的那種類數(shù)量上的爆炸式的增長，在這里又出現(xiàn)了。

新的設(shè)計方案的執(zhí)行過程如圖 10-8 所示。

Figure 10-8 Sequence diagram for new approach.

雖然這個方案比最初的那個要好那么一點點，但是還是存在類數(shù)量將會過大的問題，而且對象間的耦合也存在問題。

也就是說，我還是不想維護(hù)這樣的代碼，一定還會有更好的方案的！

替代原有設(shè)計方案
雖然我使用的替代方案并比我的原始方案優(yōu)秀多少，但是，我還是要指出來的就是，在原有方案上尋找替代方案是很重要的。太多的程序員都是抱著最開始的東西不放。當(dāng)然了，我不是說要去深入地考慮所有可替代的方案 ( 真是這樣的話，就永遠(yuǎn)停留在分析上了 ) 。然而，在遇到困難的時候，回過頭去看看是否可以在原始方案里就能夠解決這些困難。這，是很重要的。事實上，我們只是退后一步而已，明知道原來的設(shè)計方案存在這樣那樣的問題，退回來看看有沒有什么辦法可以補(bǔ)救。正是這樣，使我領(lǐng)悟到設(shè)計模式的魅力。

關(guān)于使用設(shè)計模式的一些觀察

當(dāng)人們開始關(guān)注設(shè)計模式的時候，通常他們只關(guān)心的是設(shè)計模式所提供的解決方法。這看起來不無道理，因為設(shè)計模式不是一直都被說成是能夠提供一些好的辦法來解決我們手頭上的難題么？

然而，這樣的看法是站在我們遇到一個難題的基礎(chǔ)上提出來的。實際上，在運用設(shè)計模式到設(shè)計中之間，你應(yīng)該首先明白你的設(shè)計將會做什么。正確的做法應(yīng)該是考慮一下你可以在設(shè)計中的哪些地方用到設(shè)計模式，這將告訴你要做什么，而不是什么時候我要用設(shè)計模式了，也不是為什么我要去用設(shè)計模式。

我發(fā)現(xiàn)，關(guān)心一下一個設(shè)計模式將會處理的問題的方式很有用。這樣，我就會知道什么時候，為什么要使用到這個模式。

當(dāng)你的一個抽象有很多種實現(xiàn)方法的時候，你就會發(fā)現(xiàn) Bridge 模式的妙用。它可以讓你的抽象和實現(xiàn)各自獨立的發(fā)生變化。

我們一直在討論的這個繪圖的問題就很符合 Bridge 模式的應(yīng)用場合。因此，我知道，我應(yīng)該在這個設(shè)計里用到 Bridge 模式了，雖然，到目前位置，我還不知道我該怎么做。讓抽象和實現(xiàn)可以實現(xiàn)獨立的變化意味著我可以任意的添加新的抽象而不用去修改原有的具體實現(xiàn)。

而當(dāng)前的方案還不允許這樣的獨立變化。

有一點很重要，就是即使在不知道具體怎么實現(xiàn) Bridge 模式的情況下，你還是可以肯定 Bridge 模式在這個設(shè)計中是很有用的。以后你就會發(fā)現(xiàn)，這種情況在設(shè)計模式領(lǐng)域里很常見，那就是，你可以確定你應(yīng)該把某個模式應(yīng)用到你的設(shè)計當(dāng)中，盡管，你還并不知道該怎么去實現(xiàn)這個模式。

Bridge 模式的引出

相信你已經(jīng)很清楚我們所要處理的問題了，那么，現(xiàn)在我們就用 Bridge 模式來解決我們的問題。這個過程將幫助你更加深入地理解這個復(fù)雜而強(qiáng)大的 Bridge 模式。

我們還是要遵循那兩個“原則”：

1. 找到什么是變化的并封裝它。

2. 盡量使用聚合而不是繼承。

以前，開發(fā)人員總是依靠大量的繼承來處理程序中的變化，而第二個“原則”告訴我要盡可能的使用聚合。使用聚合的目的就是讓程序可以在單獨的類里面包含它自己的變化，這樣，今后有新變化出現(xiàn)的時候就可以通過添加新的類來包含這個變化，而不會對原先的類造成影響。要達(dá)到這個目的，我們就需要把所有的變化都包含到它們共同的抽象類里面，然后，我們再去考慮抽象類之間的聯(lián)系，而不再考慮抽象類的具體實現(xiàn)。

再說封裝

很多面向?qū)ο蟪绦蛟O(shè)計的開發(fā)人員都知道“封裝”就是數(shù)據(jù)隱藏。其實，這是一個很狹隘的定義！實際上，“封裝”除了數(shù)據(jù)隱藏以外，還有很多其他的用法。如果你再回過頭去看看圖 7-2 ，你會在里面發(fā)現(xiàn)“封裝”可以操縱很多個層次。當(dāng)然，那里，封裝的目的就是為每個 Shape 做數(shù)據(jù)隱藏。然而，要注意的是， Client 對象并不知道它所處理的 Shape 的具體類型 ( 到底是 Rectangle 還是 Circle) 。因此，那個具體被 Client 所處理的類就通過 Shape 而實現(xiàn)了隱藏 ( 也就是封裝 ) ，這也就是 GoF 在說到“找到什么是變化的并封裝它”的時候所指的“封裝”，讓抽象類 (Shape) 出面去和 Client 對象交互，具體的 Rectangle 、 Circle 這些類都“躲”在了 Shape 類的后面， Client 只知道自己在和 Shape 交互，其他一無所知。

現(xiàn)在我具體討論一下本章里一直在講的這個繪圖的例子。

首先，找出什么是變化的。在這個例子里，也就是不同的形狀和不同的繪圖程序。而這些不同的形狀、不同的繪圖程序在概念上，分屬于“形狀”和“繪圖程序”，這樣，我就可以用 10-9 所示的類來代表這些不同的形狀和程序 ( 注意圖里面的類名是斜體的，這表示他們都是抽象類 ) 。

Figure 10-9 What is varying?

這樣，我打算用 Shape 來封裝這個例子里的所有的不同的形狀，而代表這些不同的形狀的類將必須自己能夠完成他本身的繪制工作。 Drawing 類的對象將僅僅負(fù)責(zé)完成“線”和“圓”等具體線條的繪制工作。這些具體的繪制，都將通過在類里定義的一些方法來完成。

現(xiàn)在我們已經(jīng)很抽象地表示出“形狀”和“繪圖程序”了，下一步，就是怎么表示具體的形狀和具體的繪圖程序的問題了。我有的“形狀”是矩形和圓，那么，我就從 Shape 里派生出 Rectangle 和 Circle 來分別代表矩形和圓。“繪圖程序”我必須使用已有的 DP1 和 DP2 ，但是我又不能直接使用它們，所以，我可以從 Drawing 派生出 V1Drawing 和 V2Drawing ，讓他們分別去使用 DP1 和 DP2 。這樣，就得到如圖 10-10 所示的類圖。

Figure 10-10 Represent the variations.

到目前為止，這一切看起來還是有點抽象。我只說了 V1Drawing 和 V2Drawing 要分別對應(yīng)地使用到 DP1 和 DP2 ，但是我還沒有說怎么用。我只是把整個例子中存在的一些變化找了出來而已。

有了這兩組類，我現(xiàn)在要關(guān)心的就是它們之間怎么彼此關(guān)聯(lián)起來的問題了。我不想再出現(xiàn)一組用同樣繼承的方式出現(xiàn)的類，這樣的結(jié)果我已經(jīng)很清楚了 ( 再回過頭去看看圖 10-3 和 10-7 ，加深點印象 ) 。相反地，我在想，我是不是可以通過用一組類使用另一組的方式來完成 ( 這不就是用聚合了嗎？ ) ?，F(xiàn)在的問題是，兩組類，到底誰用誰？

很明顯的兩種可能性：要么在 Shape 里用到 Drawing ，要么反過來， Drawing 里用到 Shape 。

我們先來看看后面這種 Drawing 里使用 Shape 的情況，如果繪圖程序直接使用到具體的形狀，那么這些程序就必須知道該怎么去完成這些具體形狀的繪制。但是，這些形狀僅僅只知道如何完成“線”和“圓”這些簡單線條的繪制，這，超出了它們的能力范圍。

那么，再看看前面的那種情況。如果在 Shape 里用 Drawing 會怎么樣？ Shape 將沒有必要知道它所使用的 Drawing 的確切類型，因為，我們已經(jīng)用 Drawing 封裝了 V1Drawing 和 V2Drawing 。 這樣看起來不錯，就像圖 10-11 所示的那樣。

Figure 10-11 Tie the classes together.

在這個設(shè)計里， Shape 通過 Drawing 來完成自己的繪制。這里，我略去了 V1Drawing 使用 DP1 和 V2Drawing 使用 DP2 的細(xì)節(jié)，在圖 10-12 里，我把這些都表示了出來還加入了一些 protected 的方法。

Figure 10-12 Expanding the design.

圖 10-13 所示的是把 Shape( 抽象 ) 和 Drawing( 實現(xiàn) ) 分離開來。

Figure 10-13 Class diagram illustrating separation of abstraction and implementation.

一個規(guī)則，一個地方

我們必須遵循的一個非常重要的實現(xiàn)策略就是，一個規(guī)則僅僅應(yīng)用到一個地方。也就是說，如果你有一個處理事務(wù)的規(guī)則，這個規(guī)則就僅用一次就好。很顯然這會導(dǎo)致設(shè)計里出現(xiàn)很多的小方法。但是，這么做你可以避免一些預(yù)想不到的問題的出現(xiàn)，可以避免因為規(guī)則相似，而復(fù)制原有代碼再修改滿足新規(guī)則的情況，而這么做的代價是很小的。 雖然 Rectangle 或者 draw() 方法都可以直接操縱 Shape 的任意的 Drawing 對象，我可以通過使用下面的“一個規(guī)則，一個地方”的策略來改進(jìn)這點。我讓 Shape 的 drawLine() 方法來調(diào)用 Drawing 對象的 drawLine() 。 當(dāng)然，凡事也不是那么的絕對。如果，我認(rèn)為某個地方應(yīng)該一直遵守某種規(guī)則的話，就像這個例子一樣。我的 Shape 類有個 drawLine() ，因為它代表著我要用 Drawing 來繪制一條直線；我同樣可以用這樣的方式創(chuàng)建一個 drawCircle() ，因為它代表著用 Drawing 繪制一個圓。

站在各個類里面的具體方法 (method) 的角度來看，這和基于繼承的設(shè)計方案 ( 如圖 10-3) 沒什么不同。如果非要說有什么不同，那就是現(xiàn)在這些方法存在的位置不同，他們不再是在同一個類里面，而是被分散到多個類里面。

在這一章一開始我就說了，我對 Bridge 模式的困惑是源于我對“實現(xiàn)”的誤解。我以為“實現(xiàn)”指的是怎么實現(xiàn)一個具體的抽象。

是 bridge 模式讓我意識到，應(yīng)該把“實現(xiàn)”看作是一個對象以外的東西，是一個為對象所用的東西。用這樣的方式著手設(shè)計，在不同的繼承鏈里包含各自的變化。圖 10-13 左側(cè)的繼承鏈包含了抽象的變化，右側(cè)的繼承鏈包含的則是我如何實現(xiàn)這些抽象的變化。這和我們說要“盡量使用聚合而不是繼承”的原則相一致。

雖然在整個設(shè)計里有不少的類，但是，你只要牢記一點，你一次要處理的就只有三個對象，這樣你的思路就會很清晰。

Figure 10-14 There are only three objects at a time.

Example 10-3 Java Code Fragments

回顧 Bridge 模式