程序設計模式的有趣解釋－追MM

創建型模式

1、 FACTORY 一追MM少不了請吃飯了，麥當勞的雞翅和肯德基的雞翅都是MM愛吃的東西，雖然口味有所不同，但不管你帶MM去麥當勞或肯德基，只管向服務員說“來四個雞翅”就行了。麥當勞和肯德基就是生產雞翅的Factory

工廠模式 ：客戶類和工廠類分開。消費者任何時候需要某種產品，只需向工廠請求即可。消費者無須修改就可以接納新產品。缺點是當產品修改時，工廠類也要做相應的修改。如：如何創建及如何向客戶端提供。

2、 BUILDER ―MM最愛聽的就是“我愛你”這句話了，見到不同地方的MM,要能夠用她們的方言跟她說這句話哦，我有一個多種語言翻譯機，上面每種語言都有一個按鍵，見到MM我只要按對應的鍵，它就能夠用相應的語言說出“我愛你”這句話了，國外的MM 也可以輕松搞掂，這就是我的“我愛你”builder。（這一定比美軍在伊拉克用的翻譯機好賣）

建造模式 ：將產品的內部表象和產品的生成過程分割開來，從而使一個建造過程生成具有不同的內部表象的產品對象。建造模式使得產品內部表象可以獨立的變化，客戶不必知道產品內部組成的細節。建造模式可以強制實行一種分步驟進行的建造過程。

3、 FACTORY METHOD ―請MM去麥當勞吃漢堡，不同的MM有不同的口味，要每個都記住是一件煩人的事情，我一般采用Factory?Method模式，帶著MM到服務員那兒，說“要一個漢堡”，具體要什么樣的漢堡呢，讓MM直接跟服務員說就行了。

工廠方法模式 ：核心工廠類不再負責所有產品的創建，而是將具體創建的工作交給子類去做，成為一個抽象工廠角色，僅負責給出具體工廠類必須實現的接口，而不接觸哪一個產品類應當被實例化這種細節。

4、 PROTOTYPE ―跟MM用QQ聊天，一定要說些深情的話語了，我搜集了好多肉麻的情話，需要時只要copy出來放到QQ里面就行了，這就是我的情話prototype了。（100塊錢一份，你要不要）

原始模型模式 ：通過給出一個原型對象來指明所要創建的對象的類型，然后用復制這個原型對象的方法創建出更多同類型的對象。原始模型模式允許動態的增加或減少產品類，產品類不需要非得有任何事先確定的等級結構，原始模型模式適用于任何的等級結構。缺點是每一個類都必須配備一個克隆方法。

5、 SINGLETON ―俺有6個漂亮的老婆，她們的老公都是我，我就是我們家里的老公Sigleton，她們只要說道“老公”，都是指的同一個人，那就是我(剛才做了個夢啦，哪有這么好的事)

單例模式 ：單例模式確保某一個類只有一個實例，而且自行實例化并向整個系統提供這個實例單例模式。單例模式只應在有真正的“單一實例”的需求時才可使用。

結構型模式

6、 ADAPTER ―在朋友聚會上碰到了一個美女Sarah，從香港來的，可我不會說粵語，她不會說普通話，只好求助于我的朋友kent了，他作為我和Sarah之間的Adapter，讓我和Sarah可以相互交談了(也不知道他會不會耍我)

適配器（變壓器）模式 ：把一個類的接口變換成客戶端所期待的另一種接口，從而使原本因接口原因不匹配而無法一起工作的兩個類能夠一起工作。適配類可以根據參數返還一個合適的實例給客戶端。

7、 BRIDGE ―早上碰到MM，要說早上好，晚上碰到MM，要說晚上好；碰到MM穿了件新衣服，要說你的衣服好漂亮哦，碰到MM新做的發型，要說你的頭發好漂亮哦。不要問我“早上碰到MM新做了個發型怎么說”這種問題，自己用BRIDGE組合一下不就行了

橋梁模式 ：將抽象化與實現化脫耦，使得二者可以獨立的變化，也就是說將他們之間的強關聯變成弱關聯，也就是指在一個軟件系統的抽象化和實現化之間使用組合/聚合關系而不是繼承關系，從而使兩者可以獨立的變化。

8、 COMPOSITE ―Mary今天過生日?！拔疫^生日，你要送我一件禮物?！薄班?，好吧，去商店，你自己挑?！薄斑@件T恤挺漂亮，買，這條裙子好看，買，這個包也不錯，買?！薄拔?，買了三件了呀，我只答應送一件禮物的哦?！薄笆裁囱?，T恤加裙子加包包，正好配成一套呀，小姐，麻煩你包起來?！薄啊保琈M都會用Composite模式了，你會了沒有？

合成模式 ：合成模式將對象組織到樹結構中，可以用來描述整體與部分的關系。合成模式就是一個處理對象的樹結構的模式。合成模式把部分與整體的關系用樹結構表示出來。合成模式使得客戶端把一個個單獨的成分對象和由他們復合而成的合成對象同等看待。

9、 DECORATOR ―Mary過完輪到Sarly過生日，還是不要叫她自己挑了，不然這個月伙食費肯定玩完，拿出我去年在華山頂上照的照片，在背面寫上“最好的的禮物，就是愛你的Fita”，再到街上禮品店買了個像框（賣禮品的MM也很漂亮哦），再找隔壁搞美術設計的Mike設計了一個漂亮的盒子裝起來……，我們都是Decorator，最終都在修飾我這個人呀，怎么樣，看懂了嗎？

裝飾模式 ：裝飾模式以對客戶端透明的方式擴展對象的功能，是繼承關系的一個替代方案，提供比繼承更多的靈活性。動態給一個對象增加功能，這些功能可以再動態的撤消。增加由一些基本功能的排列組合而產生的非常大量的功能。

10、 FACADE ―我有一個專業的Nikon相機，我就喜歡自己手動調光圈、快門，這樣照出來的照片才專業，但MM可不懂這些，教了半天也不會。幸好相機有Facade設計模式，把相機調整到自動檔，只要對準目標按快門就行了，一切由相機自動調整，這樣 MM也可以用這個相機給我拍張照片了。

門面模式 ：外部與一個子系統的通信必須通過一個統一的門面對象進行。門面模式提供一個高層次的接口，使得子系統更易于使用。每一個子系統只有一個門面類，而且此門面類只有一個實例，也就是說它是一個單例模式。但整個系統可以有多個門面類。

11、 FLYWEIGHT ―每天跟MM發短信，手指都累死了，最近買了個新手機，可以把一些常用的句子存在手機里，要用的時候，直接拿出來，在前面加上MM的名字就可以發送了，再不用一個字一個字敲了。共享的句子就是Flyweight，MM的名字就是提取出來的外部特征，根據上下文情況使用。

享元模式 ：FLYWEIGHT在拳擊比賽中指最輕量級。享元模式以共享的方式高效的支持大量的細粒度對象。享元模式能做到共享的關鍵是區分內蘊狀態和外蘊狀態。內蘊狀態存儲在享元內部，不會隨環境的改變而有所不同。外蘊狀態是隨環境的改變而改變的。外蘊狀態不能影響內蘊狀態，它們是相互獨立的。將可以共享的狀態和不可以共享的狀態從常規類中區分開來，將不可以共享的狀態從類里剔除出去。客戶端不可以直接創建被共享的對象，而應當使用一個工廠對象負責創建被共享的對象。享元模式大幅度的降低內存中對象的數量。

12、 PROXY ―跟MM在網上聊天，一開頭總是“hi,你好”,“你從哪兒來呀？”“你多大了？”“身高多少呀？”這些話，真煩人，寫個程序做為我的Proxy吧，凡是接收到這些話都設置好了自動的回答，接收到其他的話時再通知我回答，怎么樣，酷吧。?

代理模式 ：代理模式給某一個對象提供一個代理對象，并由代理對象控制對源對象的引用。代理就是一個人或一個機構代表另一個人或者一個機構采取行動。某些情況下，客戶不想或者不能夠直接引用一個對象，代理對象可以在客戶和目標對象直接起到中介的作用?？蛻舳朔直娌怀龃碇黝}對象與真實主題對象。代理模式可以并不知道真正的被代理對象，而僅僅持有一個被代理對象的接口，這時候代理對象不能夠創建被代理對象，被代理對象必須有系統的其他角色代為創建并傳入。

行為模式

13、 CHAIN?OF?RESPONSIBLEITY ―晚上去上英語課，為了好開溜坐到了最后一排，哇，前面坐了好幾個漂亮的MM哎，找張紙條，寫上“Hi,可以做我的女朋友嗎？如果不愿意請向前傳”，紙條就一個接一個的傳上去了，糟糕，傳到第一排的M M把紙條傳給老師了，聽說是個老處女呀，快跑!

責任鏈模式 ：在責任鏈模式中，很多對象由每一個對象對其下家的引用而接

起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個對象決定處理此請求。客戶并不知道鏈上的哪一個對象最終處理這個請求，系統可以在不影響客戶端的情況下動態的重新組織鏈和分配責任。處理者有兩個選擇：承擔責任或者把責任推給下家。一個請求可以最終不被任何接收端對象所接受。

14、 COMMAND ―俺有一個MM家里管得特別嚴，沒法見面，只好借助于她弟弟在我們倆之間傳送信息，她對我有什么指示，就寫一張紙條讓她弟弟帶給我。這不，她弟弟又傳送過來一個COMMAND，為了感謝他，我請他吃了碗雜醬面，哪知道他說：“我同時給我姐姐三個男朋友送COMMAND，就數你最小氣，才請我吃面?！?，:-(

命令模式 ：命令模式把一個請求或者操作封裝到一個對象中。命令模式把發出命令的責任和執行命令的責任分割開，委派給不同的對象。命令模式允許請求的一方和發送的一方獨立開來，使得請求的一方不必知道接收請求的一方的接口，更不必知道請求是怎么被接收，以及操作是否執行，何時被執行以及是怎么被執行的。系統支持命令的撤消。

15、 INTERPRETER ―俺有一個《泡MM真經》，上面有各種泡MM的攻略，比如說去吃西餐的步驟、去看電影的方法等等，跟MM約會時，只要做一個Interpreter，照著上面的腳本執行就可以了。

解釋器模式 ：給定一個語言后，解釋器模式可以定義出其文法的一種表示，并同時提供一個解釋器?？蛻舳丝梢允褂眠@個解釋器來解釋這個語言中的句子。解釋器模式將描述怎樣在有了一個簡單的文法后，使用模式設計解釋這些語句。在解釋器模式里面提到的語言是指任何解釋器對象能夠解釋的任何組合。在解釋器模式中需要定義一個代表文法的命令類的等級結構，也就是一系列的組合規則。每一個命令對象都有一個解釋方法，代表對命令對象的解釋。命令對象的等級結構中的對象的任何排列組合都是一個語言。

16、 ITERATOR ―我愛上了Mary，不顧一切的向她求婚。

Mary：“想要我跟你結婚，得答應我的條件”

我：“什么條件我都答應，你說吧”

Mary：“我看上了那個一克拉的鉆石”

我：“我買，我買，還有嗎？”

Mary：“我看上了湖邊的那棟別墅”

我：“我買，我買，還有嗎？”

Mary：“你的小弟弟必須要有50cm長”

我腦袋嗡的一聲，坐在椅子上，一咬牙：“我剪，我剪，還有嗎？”

……

迭代子模式 ：迭代子模式可以順序訪問一個聚集中的元素而不必暴露聚集的內部表象。多個對象聚在一起形成的總體稱之為聚集，聚集對象是能夠包容一組對象的容器對象。迭代子模式將迭代邏輯封裝到一個獨立的子對象中，從而與聚集本身隔開。迭代子模式簡化了聚集的界面。每一個聚集對象都可以有一個或一個以上的迭代子對象，每一個迭代子的迭代狀態可以是彼此獨立的。迭代算法可以獨立于聚集角色變化。

17、 MEDIATOR ―四個MM打麻將，相互之間誰應該給誰多少錢算不清楚了，幸虧當時我在旁邊，按照各自的籌碼數算錢，賺了錢的從我這里拿，賠了錢的也付給我，一切就OK啦，俺得到了四個MM的電話。

調停者模式 ：調停者模式包裝了一系列對象相互作用的方式，使得這些對象不必相互明顯作用。從而使他們可以松散偶合。當某些對象之間的作用發生改變時，不會立即影響其他的一些對象之間的作用。保證這些作用可以彼此獨立的變化。調停者模式將多對多的相互作用轉化為一對多的相互作用。調停者模式將對象的行為和協作抽象化，把對象在小尺度的行為上與其他對象的相互作用分開處理。

18、 MEMENTO ―同時跟幾個MM聊天時，一定要記清楚剛才跟MM說了些什么話，不然MM發現了會不高興的哦，幸虧我有個備忘錄，剛才與哪個MM說了什么話我都拷貝一份放到備忘錄里面保存，這樣可以隨時察看以前的記錄啦。

備忘錄模式 ：備忘錄對象是一個用來存儲另外一個對象內部狀態的快照的對象。備忘錄模式的用意是在不破壞封裝的條件下，將一個對象的狀態捉住，并外部化，存儲起來，從而可以在將來合適的時候把這個對象還原到存儲起來的狀態。

19、 OBSERVER ―想知道咱們公司最新MM情報嗎？加入公司的MM情報郵件組就行了，tom負責搜集情報，他發現的新情報不用一個一個通知我們，直接發布給郵件組，我們作為訂閱者（觀察者）就可以及時收到情報啦

觀察者模式 ：觀察者模式定義了一種一隊多的依賴關系，讓多個觀察者對象同時監聽某一個主題對象。這個主題對象在狀態上發生變化時，會通知所有觀察者對象，使他們能夠自動更新自己。

20、 STATE ―跟MM交往時，一定要注意她的狀態哦，在不同的狀態時她的行為會有不同，比如你約她今天晚上去看電影，對你沒興趣的MM就會說“有事情啦”，對你不討厭但還沒喜歡上的MM就會說“好啊，不過可以帶上我同事么？”，已經喜歡上你的MM就會說“幾點鐘？看完電影再去泡吧怎么樣？”，當然你看電影過程中表現良好的話，也可以把MM的狀態從不討厭不喜歡變成喜歡哦。

狀態模式 ：狀態模式允許一個對象在其內部狀態改變的時候改變行為。這個對象看上去象是改變了它的類一樣。狀態模式把所研究的對象的行為包裝在不同的狀態對象里，每一個狀態對象都屬于一個抽象狀態類的一個子類。狀態模式的意圖是讓一個對象在其內部狀態改變的時候，其行為也隨之改變。狀態模式需要對每一個系統可能取得的狀態創立一個狀態類的子類。當系統的狀態變化時，系統便改變所選的子類。

21、 STRATEGY ―跟不同類型的MM約會，要用不同的策略，有的請電影比較好，有的則去吃小吃效果不錯，有的去海邊浪漫最合適，單目的都是為了得到MM的芳心，我的追MM錦囊中有好多Strategy哦。

策略模式 ：策略模式針對一組算法，將每一個算法封裝到具有共同接口的獨立的類中，從而使得它們可以相互替換。策略模式使得算法可以在不影響到客戶端的情況下發生變化。策略模式把行為和環境分開。環境類負責維持和查詢行為類，各種算法在具體的策略類中提供。由于算法和環境獨立開來，算法的增減，修改都不會影響到環境和客戶端。

22、 TEMPLATE?METHOD ――看過《如何說服女生上床》這部經典文章嗎？女生從認識到上床的不變的步驟分為巧遇、打破僵局、展開追求、接吻、前戲、動手、愛撫、進去八大步驟(Template method)，但每個步驟針對不同的情況，都有不一樣的做法，這就要看你隨機應變啦(具體實現)；

模板方法模式 ：模板方法模式準備一個抽象類，將部分邏輯以具體方法以及具體構造子的形式實現，然后聲明一些抽象方法來迫使子類實現剩余的邏輯。不同的子類可以以不同的方式實現這些抽象方法，從而對剩余的邏輯有不同的實現。先制定一個頂級邏輯框架，而將邏輯的細節留給具體的子類去實現。

23、 VISITOR ―情人節到了，要給每個MM送一束鮮花和一張卡片，可是每個MM送的花都要針對她個人的特點，每張卡片也要根據個人的特點來挑，我一個人哪搞得清楚，還是找花店老板和禮品店老板做一下Visitor，讓花店老板根據MM的特點選一束花，讓禮品店老板也根據每個人特點選一張卡，這樣就輕松多了；

訪問者模式 ：訪問者模式的目的是封裝一些施加于某種數據結構元素之上的操作。一旦這些操作需要修改的話，接受這個操作的數據結構可以保持不變。訪問者模式適用于數據結構相對未定的系統，它把數據結構和作用于結構上的操作之間的耦合解脫開，使得操作集合可以相對自由的演化。訪問者模式使得增加新的操作變的很容易，就是增加一個新的訪問者類。訪問者模式將有關的行為集中到一個訪問者對象中，而不是分散到一個個的節點類中。當使用訪問者模式時，要將盡可能多的對象瀏覽邏輯放在訪問者類中，而不是放到它的子類中。訪問者模式可以跨過幾個類的等級結構訪問屬于不同的等級結構的成員類。

---

與籃球共舞，盡顯模式本色

==創建型模式==

1、 =SIMPLE FACTORY=
打完籃球真累，正好邊上有個小攤。
“來杯可樂。”
“我要芬達。”
“一瓶礦泉水?！?

工廠模式：客戶類和工廠類分開。消費者任何時候需要某種產品，只需向工廠請求即可。消費者無須修改就可以接納新產品。有了小攤這個工廠，我們口渴的問題就很 easy的解決了。

2、 =FACTORY METHOD=
以前每次下午打完籃球后一般很晚，回來再洗個澡，食堂就關門了。我們就集體跑過西三門外吃牛肉面（呵呵，人生之一大爽事?。總€餐廳的風味還不一樣，這無所謂啦，我們只要說一句“來碗牛肉面“就行了。

工廠方法模式：核心工廠類不再負責所有產品的創建，而是將具體創建的工作交給子類去做，成為一個抽象工廠角色，僅負責給出具體工廠類必須實現的接口，而不接觸哪一個產品類應當被實例化這種細節。每一個餐廳就是一個具體的工廠，可惜現在西三門已經關掉了，郁悶 ing！

3、 =SINGLETON=
Kobe就是Kobe，不管你是從電視上看到，還是從報紙上看到，其實就是他一個人

單例模式：單例模式確保某一個類只有一個實例，而且自行實例化并向整個系統提供這個實例單例模式。組織后衛可以有幾個，但 Kobe只能有一個，廢話！

4、 =BUILDER=
NBA中強隊頗多，且各有自己的特點，因此對付不同的隊有不同的打法，但你只要說“今天打國王”就行了，具體該怎么打由教練去安排（build）就行了。

建造模式：將產品的內部表象和客戶端分來，客戶不必知道產品內部組成的細節，因此當產品的表象一般很復雜時才用。戰術安排的確是個比較專業的任務，所以 …。

5、 =PROTOTYPE=
今年全明星賽真不錯，真想再看一遍。
“小陳，把serv-u開一下，我下你的全明星賽?！?
“OK！不過先上傳兩部好片。”
“啊，我暈~~!”

原始模型模式：實際上就是復制啦。原始模型模式允許動態的增加或減少產品類，產品類適合于任何的等級結構。缺點是每一個類都必須配備一個克隆方法。還好， Windows里面的東東只要點右鍵，都有個復制選項。

==結構型模式==

6、 =ADAPTER=
姚明剛去火箭時，交流有點不便，但通過經紀人Adapter，姚明很快就和火箭的其他人混熟了。

適配器模式：把一個類的接口變換成客戶端所期待的另一種接口，從而使原本因接口原因不匹配而無法一起工作的兩個類能夠一起工作。通過經紀人 Adapter，主教練就可以把姚明看作本土人（會說e文的人）。如今姚明已經加強了功能，使得不要經紀人也可以和主教練交流，呵呵，str man！

7、 =COMPOSITE=
上半場被灌了個50：25，趁中場暫停，大家一起來安排下半場怎么打：
“方案A：6號太準，要專人盯防。”?D“就是就是！”
“方案B：左邊防守太弱，把XX換上來?！保昂靡靡　?
“方案C：進攻太差，多打一些擋差?！保安诲e不錯！”
“方案D：上半場方案X其實還是不錯的，下半場go on?！保癘KOK！“
…
一聲哨響，下半場開始，我們把方案A，B，C…結合，定為方案Y。＠＃￥%＾＆＊（！~等一系列后，我們終于以51:50戰勝對手，哈哈…??！白日夢＃＆＠＊！

合成模式：合成模式使得客戶端把單獨的成分對象和由他們復合而成的合成對象同等看待，因此合成模式使得客戶端增加新的構件變得容易。方案 A是一條簡單的方案，方案D是由不同的方案結合而成的復雜方案，但我們不管這些，我們只知道它們都是我們所要的方案。

8、 =DECORATOR=
記得西邊操場沒修好時，我們踢球沒有地盤，還好，有個籃球場是空的，我們便撿來幾塊磚頭，擺上兩個門，哈哈，這樣，籃球場也就變成小足球場了。
系里舉辦一個舞會，得找塊大點的地盤，我們又看中了籃球場，掛起一盞燈，搬來兩個音箱，ok，一切搞定。這樣，籃球場便變成了舞會廳了，哈哈。

裝飾模式：裝飾模式以對客戶端透明的方式擴展對象的功能，是繼承關系的一個替代方案，提供比繼承更多的靈活性。其實，籃球場還可以變成很多其它的東東，只要發揮你的想像，嘻嘻。

9、 =PROXY=
玩NBA正happying。
突然，小付跑過來說：“你的電話，X系說明天下午兩點要跟俺們系干一場，怎么樣？”
－“OK，就跟他們說沒問題！”玩Games要緊。
小付作為一個代理倒省了俺不少事，呵呵。

代理模式：代理就是一個人或一個機構代表另一個人或者一個機構采取行動。某些情況下，客戶不想或者不能夠直接引用一個對象，代理對象可以在客戶和目標對象直接起到中介的作用?？蛻舳朔直娌怀龃碇黝}對象與真實主題對象。代理模式可以并不知道真正的被代理對象，而僅僅持有一個被代理對象的接口，這時候代理對象不能夠創建被代理對象，被代理對象必須有系統的其他角色代為創建并傳入。X系只知道我們同意和他們干一場，但并不知道是回答他們的就是小付。

10、 =FLYWEIGHT=
上次說到吃牛肉面，我們當中有幾個還特挑剔。這不：
“老板，我要麻辣的。”－“好咧！”唰唰，老板放了些辣醬。
“我要川味的。”－“好咧！”唰唰，老板放了些泡菜。
“我也要川味的?！保习灏磩偛诺臉邮接肿隽艘槐?。
小陳一看大家都要，不服，就說：“老板，俺要黑的。”
“黑的？黑的是什么樣的?！崩习寮{悶了。
“黑的，黑的就是多放些醬油…”－全場狂暈＃＆＊%

享元模式：享元模式以共享的方式高效的支持大量的細粒度對象。享元模式能做到共享的關鍵是其狀態存儲在享元內部，不會隨環境的改變而有所不同。將可以共享的狀態和不可以共享的狀態從常規類中區分開來，把不可以共享的狀態從類里剔除出去?？蛻舳藦墓S中獲得對象時，工廠會先檢查其是否有該對象，如果有則直接返回給客戶，沒有才創建新的實例。享元模式大幅度的降低內存中對象的數量。那些麻辣啦，川味啦，都是享元，要的牛肉面有很多，但口味卻就那么幾種。后來，我們打玩籃球又去了那家店，還沒等過小陳開口，老板就說：“這位同學，你是要黑牛肉面吧?！保￡悺啊?

11、=FACADE=
又要和X系開始一季一度的比賽了，具體時間和地點還得靠俺這個隊長來搞定，好，no problem！給X系籃球隊隊長一個call：“星期六下午3：00，我們一見高下?！?

門面模式：門面模式提供一個高層次的接口，使得子系統更易于使用，它將客戶端和一些子系統分離，提高子系統的獨立性和可移植性。X系籃球隊隊長就是個Facade，通過他，免得我要去跟他們系隊員（子系統）一個個去通知。

12、=BRIDGE=
我是個學生，但在籃球隊里，我又是個隊員，那你說我是什么，超級賽亞人？呵呵。

橋梁模式：將抽象化與實現化脫耦，使得二者可以獨立的變化，也就是說將他們之間的強關聯變成弱關聯，也就是指在一個軟件系統的抽象化和實現化之間使用組合 /聚合關系而不是繼承關系，從而使兩者可以獨立的變化。哈哈，多虧這個模式，不然我還真不知道該怎么稱呼我自己呢，嘻嘻。

==行為模式==

13、=STRATEGY=
足球里有很多戰術，比如，一般情況用442，打強隊可以用451，打弱隊可以用343。
當然籃球里面也有的，比如，你可以選擇打中鋒，或者遠投，當然我們平時最多用的可能就是獨干，哈哈。

策略模式：策略模式針對一組算法，將每一個算法封裝到具有共同接口的獨立的類中，從而使得它們可以相互替換。策略模式使得算法可以在不影響到客戶端的情況下發生變化。策略模式把行為和環境分開。環境類負責維持和查詢行為類，各種算法在具體的策略類中提供。由于算法和環境獨立開來，算法的增減，修改都不會影響到環境和客戶端。

14、=TEMPLATE METHOD=
不同的籃球班有不同的老師，但他們上課的內容都是一樣的，一般都分為運球，傳球，投籃，上籃這么幾堂課，估計體育師范學院教書的模版就是這樣。具體運球怎么教，上籃怎么教就依不同的老師自己了。

模板方法模式：模板方法模準備一個抽象類，將部分邏輯以具體方法以及具體構造子的形式實現，然后聲明一些抽象方法來迫使子類實現剩余的邏輯。不同的子類可以以不同的方式實現這些抽象方法，從而對剩余的邏輯有不同的實現。先制定一個頂級邏輯框架，而將邏輯的細節留給具體的子類去實現。

15、=OBSERVER=
“今天下午去打籃球啊?！保瑼
“好啊，到時叫上我?！?－B
“也叫上我?！?－C
“還有我。”－D
…
我們班的號召力可見一斑，呵呵。

觀察者模式：觀察者模式使觀察者和被觀察者之間的耦合抽象化，被觀察者會向所有的登記過的觀察者發出通知。當A要去打籃球時，便會通知B，C，D…

16、=ITERATOR=
大一時上籃球課，體育老師要清名單：“小王（體育委員），你們班到了多少人？”
小王：“立正－－，報數?！?
“1，2，3，4，…”

迭代子模式：迭代子模式可以順序訪問一個聚集中的元素而不必暴露聚集的內部表象。迭代子模式將迭代邏輯封裝到一個獨立的子對象中，從而與聚集本身隔開。迭代子模式簡化了聚集的界面。每一個聚集對象都可以有一個或一個以上的迭代子對象，每一個迭代子的迭代狀態可以是彼此獨立的。迭代算法可以獨立于聚集角色變化。小王真聰明，不必查詢任何一個人就知道到了多少人。

17、=CHAIN OF RESPONSIBLEITY=
現在湖人隊進攻，佩頓將球交給馬龍，馬龍再傳給奧尼爾，奧尼爾一記重扣，湖人再添2分。

責任鏈模式：在責任鏈模式中，很多對象由每一個對象對其下家的引用連接起來而形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個對象決定處理此請求。客戶并不知道鏈上的哪一個對象最終處理這個請求，系統可以在不影響客戶端的情況下動態的重新組織鏈和分配責任。處理者有兩個選擇：承擔責任或者把責任推給下家。一個請求可以最終不被任何接收端對象所接受。其實剛才那個球，奧尼爾可以再傳給科比來個空中接力大風車灌籃的，那就PERFECT了！

18、=COMMAND=
一場關鍵比賽最后一秒由俺的三分決定了勝負，不過，可累壞了俺。
“來杯水?！闭媛犜?，我同學A馬上叫一靚MM給我倒了杯水。
“背好酸。”真聽話，我同學A馬上又叫那個靚MM給我錘背。
“真想洗個澡?！闭媛犜挕暗鹊龋也皇悄莻€意思，哇哇…＾￥＆＃＊。”

命令模式：命令模式把一個請求或者操作封裝到一個對象中。命令模式把發出命令的責任和執行命令的責任分割開，委派給不同的對象。命令模式允許請求的一方和發送的一方獨立開來，使得請求的一方不必知道接收請求的一方的接口，更不必知道請求是怎么被接收，以及操作是否執行，何時被執行以及是怎么被執行的。如果早知道那個命令怎么執行，俺就不會說那句話了，嗚嗚…

19、=MEMENTO=
下了一個NBA小游戲，里面可以自動調關，但要改注冊表，當然，先找到鍵值“總決賽”，右鍵，導出為final.reg，剩下來你就可以隨便改了，萬一改錯了，還可以雙擊final.reg，呵呵。

備忘錄模式：備忘錄對象是一個用來存儲另外一個對象內部狀態的快照的對象。備忘錄模式的用意是在不破壞封裝的條件下，將一個對象的狀態捉住，并與該對象分離，存儲起來，從而可以在將來合適的時候把這個對象還原到存儲起來的狀態。

20、STATE
今天打球真沒勁，投籃老委掉。
忽然，一靚MM走過來…　?。?，超級賽亞人第三階，變身！
變身之后果然不同凡響，輕松幌過兩個人，在三個人的夾擊下出手命中，同時加罰?。ê呛牵蜁担?

狀態模式：狀態模式允許一個對象在其內部狀態改變的時候改變行為。這個對象看上去像是改變了它的類一樣。狀態模式需要對每一個系統可能取得的狀態創立一個狀態類的子類。當系統的狀態變化時，系統實際改變所選的子類。當一個對象行為依賴其所處狀態時，就可以考慮用該模式。靚MM沒來時，狀態差，導致投籃委。靚MM一來，狀態奇佳，就是打手也能進，哈哈。

21、=VISITOR=
下學期籃球課換了個老師，當然，他對我們全然不熟，于是第一節課他拿著花名冊找到體育委員小王：“小陳技術怎樣？”－“一般般，”
“小羅呢？”－“還可以，不過上籃不行?！?
“小何呢？”－“他啊…”
等等，俺趕緊咳嗽一聲。
“他怎么樣？”－“他，他不錯不錯！” 哈哈。
“就是投籃老委!”－啊，你這小樣，耍我。

訪問者模式：訪問者模式的目的是封裝一些施加于某種數據結構元素之上的操作，使得增加新的操作很容易，一旦這些操作需要修改的話，接受這個操作的數據結構可以保持不變，比如，老師還可以通過小王得到我們每個人的身高等。訪問者模式可以跨過幾個類的等級結構訪問屬于不同的等級結構的成員類（比迭代子強），但增加一個新的節點就變得很困難，如果我們班來了個新同學，小王就沒那么管用了。

22、=INTERPRETER=
想知道怎么玩出酷呆了的假動作么，我這兒有AND1的經典集錦，按照上面練習就行了。

解釋器模式：給定一個語言后，解釋器模式可以定義出其文法的一種表示，并同時提供一個解釋器?？蛻舳丝梢允褂眠@個解釋器來解釋這個語言中的句子。解釋器模式將描述怎樣在有了一個簡單的文法后，使用模式設計解釋這些語句。在解釋器模式里面提到的語言是指任何解釋器對象能夠解釋的任何組合。在解釋器模式中需要定義一個代表文法的命令類的等級結構，也就是一系列的組合規則。每一個命令對象都有一個解釋方法，代表對命令對象的解釋。命令對象的等級結構中的對象的任何排列組合都是一個語言。

23、=MEDIATOR=
俺一高中同學小D到我這兒來玩，當然，打球是必不可少的。叫上小王就出去K別人，但小D和小王不熟，所以幾乎沒什么配合，結果被CAI了個5：0。只好下場“休息”。
小王：“叫你那個同學少單干，多傳球。”－“OK?！蔽疫^去把意見傳給了小D。
小D：“你那個同學防守有問題，要盯人，不要盯球?！保癗O PROBLEM?！蔽矣诌^去把意見傳給了小王。

調停者模式：調停者模式包裝了一系列對象相互作用的方式，使得這些對象不必相互明顯作用。從而使他們可以松散偶合。當某些對象之間的作用發生改變時，不會立即影響其他的一些對象之間的作用。保證這些作用可以彼此獨立的變化。調停者模式將多對多的相互作用轉化為一對多的相互作用。調停者模式將對象的行為和協作抽象化，把對象在小尺度的行為上與其他對象的相互作用分開處理。
果然，依靠我這個MEDIATOR，我們馬上還了對方一個雞蛋。哈哈！

參考： << 追 MM 和設計模式 >>
<<java< span="">與模式 >>

---

籃球中的壞味道

?

= 初始化問題 =

打半場開始之前當然要熱身啦，上次俺就是沒熱身出現 exception－－扭了腳，到現在還痛呢，555…

?

Solution: 不言自明。

注: 為避免沒初始化，常伴有大量 if(xx==null) 之類語句出現，該問題主要是把null錯看成對象的缺省值。解決此問題的一個技巧是引入一“NullObject”作為其缺省值，即把對沒初始化對象的調用轉換為對這個“NullObject”缺省對象方法的調用，這樣便可消除這些冗余的 if(xx==null)。

= Long Method =

刷刷刷，一連串的動作，帥呆了(當然是在說俺啦)。

“怎么做的，教小弟?！?

“OK?？粗冗\過去，再運過來，再這樣，再……”

“@#%*…”

真笨，教了幾十遍，他還是沒學會…

“這樣吧，換個教法，把動作分解，先來個crossover，再…”

真聰明，兩三下就學會了!!!

“原來這么簡單，一下就會了嘛，怎么不是說？”

“誰叫你不早問!”(似乎流行這么回答)

Solution: 先在這個方法體中加上注釋，然后將每個注釋塊提出為一個方法，就這么簡單。

注: Large Class等也可用類似作法。

= Long Parameter List =

為寫一篇關于籃球的文章(夠無聊的吧)。需要一些數據，如籃球的質量，體積，彈性系數等。你沒必要把這些數據一一后告訴俺，只要抱加一個籃球給俺，這些數據自然就搞定了。

Solution: 如果這幾個參數組合在一起有意義，引進一個對象，使其持有這幾個參數，然后使這個對象成為此方法的參數，并對該方法作相應的修改。

注: 可能會增加類之間的耦合。

= Primitive Obsession =

NBA中，一支球隊有個屬性表示戰績。一開始，為簡單起見，可能用一個String對象表示，如”12:7”。但如果因需要還得讓它能表示勝率，排名等，乍辦？解決方案是設計一個戰績對象，使它持有勝、負、勝率、排名等屬性，這樣就清晰明了了。

Solution: 將那些primitive or near-primitive types改成有意義的對象。

注: 面向對象就是要面向對象。

= Feature Envy =

俺有許多必殺技，其中有一技就是，聽好了，那就是叫小王先crossover，再變向，再急停…。咦，怎么都是小王？唉，這個必殺技不關俺的事，給小王算了。

Solution: 如果一方法總是調用其他某個對象的方法，就把該方法移到相應的對象中去。

注: 有時候出現這種情況是有道理的，如策略模式和訪問者模式。

= Divergent Change =

一次比賽，俺當裁判，吹哨，記分，記時俺都一人包辦。半場下來，因來回奔波累得不成人樣，還因忙不過來吹了不少“黑哨”。于是，又找來兩人，一人記分記時，另一人和俺各管半場。呵呵，果然下半場輕松加愉快，而且幾乎沒有誤判，不過俺的工資減了一半…

Solution: 如果有多種原因使得一個對象改變，就說明這個對象責任過多，得減減負(三減？)?？蓪⒃搶ο蟀葱枨蠓纸鉃槎鄠€對象。

注:? A module should have only one secret.

= Shotgun Surgery =

這次比賽，俺和小王兩人當主裁，兩個主裁，沒搞錯吧，不用急，還有更離譜的呢，那就是俺吹哨，小王負責做犯規手勢，有創意吧!不過分工似乎太“明確”了吧。呵呵。

Solution: 如果一個簡單的改變牽涉到幾個對象，也就是說一件事的責任被分散到幾個對象中，這時，你要做的就是從這些對象中提取出這整件事，然后對其他對象作相應的調整，這可能使幾個對象合并成一個對象。

注: 當然也有特例，如觀察者模式中的模型與視圖，這是因為視圖和模型通常需要獨自的改變。

參考書目

---

籃球中的Exception

　　When used to best advantage, exceptions can improve a program's readability, reliability and maintainability. When used improperly, they can have the opposite effect.

　　Playing basketball也一樣，漂亮的假動作的確可以帥呆了我，但用得不合理則只能說是花哨而不實用了。

　　Exception可分為三類，checked exceptions, runtime exceptions和errors。
　　比如，蓋帽時可能產生打手等exceptions，但這不會導致比賽就此不能進行?？梢酝ㄟ^罰球來go on. 只是你的這次蓋帽因犯規而無效，即不能得到你蓋帽數增一的結果。這類exception稱之為checked exception.

　　而有時比賽過程中，可能同于球員比現實在是糟糕，而導致觀眾鬧事（暈），比如向現場砸瓶子和水果，從而導致比賽意外中斷。比賽能不能go on. 你也不能確定。這樣便產生了一個runtime exception.

　　還有一些情況，比如比賽時，電子記分牌突然產生一個exception.74分變成了47分，這時你也只好嘆于無奈，因為這是一個error.

　　由此看來，checked exceptions是可以恢復的，即可恢復條件下應該用checked exceptions，而后兩種exceptions needn't并且通常shouldn't be caught. 其中runtime exceptions的出現意味著你的程序本身有問題，你可以通過改進球隊的戰術來解決。而errors是James Gosling的問題，不關你的事。

　　Exceptions很有用，但很多情況的exceptions是unnecessary的。
　　比如下面一個程序：
　　　while(沒有防守){
　　　　try{
　　　　　 投籃();
　　　　}catch(距離太遠Exception e){
　　　　 System.out.println("距離遠于10米，我可不想三不粘");
　　　　 }
　　　　　...
　　　}
　　這個程序可以正常運行，但如果Kobe在后場無人盯防時運球，卻不得不停地拋出"距離太遠exception"，這還真夠難為他的。改一下：
　　　while(沒有防守){
　　　　if(距離<5){
　　　　　 投籃();
　　　　}
　　　　　...
　　　}
　　這回Kobe只要睜著眼，一瞧籃框距離不遠，便可起跳了。

　　另外，一方法產生exception后，不應該改變調用該方法對象的狀態。如下這個程序就犯了這個毛病：
　　　public void 蓋帽(){
　　　　蓋帽次數++;
　　　　 if(打手)
　　　　　 throw new 打手Exception();
　　　}
　　這樣一來，一場比賽得三雙就容易了很多，呵呵。改成：
　　　public void 蓋帽(){
　　　　if(打手)
　　　　　 throw new 打手Exception();
　　　 蓋帽次數++;
　　　}
　　就行了。這個問題看似easy,卻也是最容易犯錯的地方。

　　最后還有一個問題，也是一個最普遍和最嚴重的問題，那就是:exception沒描述清楚.(地球人都知道啊^^)
　　Ignoring an exception is analogous to ignoring a fire alarm--and turning it off so no one else gets a chance to see if there's a real fire.
　　犯規時，一個裁判得如此描述：A隊6號打手犯規，犯規次數累計共3次，并由B隊罰球2次。否則，只聞一聲哨響，雙方球員爭嚷，圍住一球狂強，拳打腳踢真爽......

Java、模式、美眉、籃球