其他

12.3 完整解決方案       為了讓系統具有更好的靈活性和可擴充性，克服繼承複用所帶來的問題，Sunny公司開發人員使用裝飾模式來重構圖形介面構件庫的設計，其中部分類的基本結構12-4所示：圖12-4 圖形介面構件庫結構圖     

14.5 帶外部狀態的解決方案       Sunny軟體公司開發人員通過對圍棋棋子進行進一步分析，發現雖然黑色棋子和白色棋子可以共用，但是它們將顯示在棋盤的不同位置，如何讓相同的黑子或者白子能夠多次重複顯示且位於一個棋盤的不同地方？解決方案就是將棋子的位置定義為棋子的一個外部狀態，在需要時再進行設定。因此，我們在圖14-4中增加了一個新的類Coordinates（座標類），用於儲存每一個棋子的位置，修改之後的結構圖14-5所示：圖14-5引入外部狀態之後的圍棋棋子結構圖       在圖14-

      享元模式結構較為複雜，一般結合原廠模式一起使用，在它的結構圖中包含了一個享元工廠類，其結構圖14-3所示： 圖14-3 享元模式結構圖      在享元模式結構圖中包含如下幾個角色：      ● Flyweight（抽象享元類）：通常是一個介面或抽象類別，在抽象享元類中聲明了具體享元類公用的方法，這些方法可以向外界提供享元對象的內部資料（內部狀態），同時也可以通過這些方法來設定外部資料（外部狀態）。      ●

      有朋友一直在等待我的解譯器模式文稿，，現把某個版本發在部落格上，歡迎大家討論！       雖然目前電腦程式設計語言有好幾百種，但有時候我們還是希望能用一些簡單的語言來實現一些特定的操作，我們只要向電腦輸入一個句子或檔案，它就能夠按照預先定義的文法規則來對句子或檔案進行解釋，從而實現相應的功能。例如提供一個簡單的加法/減法解譯器，只要輸入一個加法/減法運算式，它就能夠計算出運算式結果，18-1所示，當輸入字串運算式為“1 + 2 + 3 – 4 + 1”時，將輸出計算結果為3。圖18

3.1 單例模式的動機     

14.5 單純享元模式和複合享元模式       標準的享元模式結構圖中既包含可以共用的具體享元類，也包含不可以共用的非共用具體享元類。但是在實際使用過程中，我們有時候會用到兩種特殊的享元模式：單純享元模式和複合享元模式，下面將對這兩種特殊的享元模式進行簡單的介紹：       1.單純享元模式       在單純享元模式中，所有的具體享元類都是可以共用的，不存在非共用具體享元類。單純享元模式的結構14-6所示：圖14-6 單純享元模式結構圖       2.複合享元模式      

      參考資料：MVC is dead, it's time to MOVE on. http://cirw.in/blog/time-to-move-on       作者：Conrad Irwin — June 2012     

        為了滿足“開閉原則”，大部分設計模式都引入了抽象層，如Factory 方法模式、抽象原廠模式、適配器模式、橋接模式、命令模式、策略模式等等。用戶端代碼針對抽象層編程，而在程式啟動並執行時候再指定其子類，根據“裡氏代換原則”和物件導向的多態性，子類對象在運行時將覆蓋父類對象。如果需要對系統進行擴充或修改，只需修改子類類名即可。在具體實現時，通過引入設定檔可以使得使用者在不修改任何用戶端代碼的前提下增加或替換子類，其基本實現過程如下：     

        當前咱們國家正在大力倡導構建和諧社會，其中一個很重要的組成部分就是建設資源節約型社會，“浪費可恥，節儉光榮”。在軟體系統中，有時候也會存在資源浪費的情況，例如在電腦記憶體中儲存了多個完全相同或者非常相似的對象，如果這些對象的數量太多將導致系統運行代價過高，記憶體屬於電腦的“稀缺資源”，不應該用來“隨便浪費”，那麼是否存在一種技術可以用於節約記憶體使用量空間，實現對這些相同或者相似對象的共用訪問呢？答案是肯定，這種技術就是我們本章將要學習的享元模式。14.1 圍棋棋子的設計    

      迪米特法則來自於1987年美國東北大學(Northeastern University)一個名為“Demeter”的研究項目。迪米特法則又稱為最少知識原則(LeastKnowledge Principle, LKP)，其定義如下：迪米特法則(Law of  Demeter, LoD)：一個軟體實體應當儘可能少地與其他實體發生相互作用。     

       在正式介紹橋接模式之前，我先跟大家談談兩種常見文具的區別，它們是毛筆和蠟筆。假如我們需要大中小3種型號的畫筆，能夠繪製12種不同的顏色，如果使用蠟筆，需要準備3×12 = 36支，但如果使用毛筆的話，只需要提供3種型號的毛筆，外加12個顏料盒即可，涉及到的對象個數僅為 3 + 12 =

3.3 負載平衡器的設計與實現       Sunny軟體公司承接了一個伺服器負載平衡(Load

21.5 再談備忘錄的封裝      備忘錄是一個很特殊的對象，只有原發器對它擁有控制的權力，負責人只負責管理，而其他類無法訪問到備忘錄，因此我們需要對備忘錄進行封裝。     

      沒有人買車會只買一個輪胎或者方向盤，大家買的都是一輛包含輪胎、方向盤和發動機等多個組件的完整汽車。如何將這些組件組裝成一輛完整的汽車並返回給使用者，這是建造者模式需要解決的問題。建造者模式又稱為產生器模式，它是一種較為複雜、使用頻率也相對較低的建立型模式。建造者模式為用戶端返回的不是一個簡單的產品，而是一個由多個組件組成的複雜產品。8.1 遊戲角色設計Sunny軟體公司遊戲開發小組決定開發一款名為《Sunny群俠傳》的網路遊戲，該遊戲採用主流的RPG(Role Playing

      近幾年來，設計模式試題已廣泛出現在一些IT企業（包括一些巨牛型企業）的面試和筆試題中，從本文開始我將通過幾篇文章來介紹一下一些已出現過的設計模式面試和筆試題，歡迎大家討論。某房地產公司欲開發一套房產資訊管理系統，根據如下描述選擇合適的設計模式進行設計：(1) 該公司有多種房型，如公寓、別墅等，在將來可能會增加新的房型；(2) 銷售人員每售出一套房子，主管將收到相應的銷售訊息。        參考解答：【個人觀點】      對於描述(1)可以選擇使用Factory

26.4 訪問者模式與組合模式聯用      在訪問者模式中，包含一個用於儲存元素對象集合的對象結構，我們通常可以使用迭代器來遍曆對象結構，同時具體元素之間可以存在整體與部分關係，有些元素作為容器物件，有些元素作為成員對象，可以使用組合模式來組織元素。引入組合模式後的訪問者模式結構圖26-4所示：        

3.5 一種更好的單例實現方法       餓漢式單例類不能實現消極式載入，不管將來用不用始終佔據記憶體；懶漢式單例類安全執行緒控制煩瑣，而且效能受影響。可見，無論是餓漢式單例還是懶漢式單例都存在這樣那樣的問題，有沒有一種方法，能夠將兩種單例的缺點都克服，而將兩者的優點合二為一呢？答案是：Yes！下面我們來學習這種更好的被稱之為Initializationon Demand Holder (IoDH)的技術。     

3.4 餓漢式單例與懶漢式單例的討論      Sunny公司開發人員使用單例模式實現了負載平衡器的設計，但是在實際使用中出現了一個非常嚴重的問題，當負載平衡器在啟動過程中使用者再次啟動該負載平衡器時，系統無任何異常，但當用戶端提交請求時出現請求分發失敗，通過仔細分析發現原來系統中還是存在多個負載平衡器對象，導致分發時目標伺服器不一致，從而產生衝突。為什麼會這樣呢？Sunny公司開發人員百思不得其解。     

       隨著設計模式的廣泛使用，如何在結構圖（主要是UML類圖）中標註設計模式成為大家討論的一個熱點話題。設計模式是軟體設計中的一些微結構，通過一種合理的方法來標註設計模式既有助於開發人員更好地進行設計軟體系統，也有利於理解一些遺留系統，具體來說，設計模式的標註具有以下意義：      (1) 在系統設計和實現階段，如果能夠通過一種簡單易懂的方式來標註相應的模式角色，將有助於開發人員開發和設計軟體時記錄所採用的解決方案，便於及時修改和完善設計方案，也有助於更好地理解和修改原始碼；     

26.3 完整解決方案      Sunny軟體公司開發人員使用訪問者模式對OA系統中員工資料匯總模組進行重構，使得系統可以很方便地增加新類型的訪問者，更加符合“單一職責原則”和“開閉原則”，重構後的基本結構26-3所示：