（一）
一開始我打算好好研究常見的幾種設(shè)計模式，搞清楚他們各自適用的場景百侧，方便以后懂得運用在項目中砰识，讓代碼更優(yōu)雅。復(fù)習(xí)了代理模式佣渴、適配者模式辫狼、工廠模式、建造者模式辛润、裝飾者模式膨处、觀察者模式后，我才明白——
23種設(shè)計模式按照使用目的來分砂竖，可以分為創(chuàng)建型模式真椿、結(jié)構(gòu)型模式和行為型模式。創(chuàng)建型模式用來處理對象的創(chuàng)建過程乎澄；結(jié)構(gòu)型模式用來處理類或者對象的組合突硝；行為型模式用來對類或?qū)ο笤鯓咏换ズ驮鯓臃峙渎氊?zé)進行描述。
在項目經(jīng)驗不足的情況下置济，一定要多靜下心思考各種模式本質(zhì)本質(zhì)本質(zhì)解決的問題到底是什么解恰。看清自己的實力浙于，對自己要求高一點护盈。在現(xiàn)實開發(fā)中，對于不同類型的代碼羞酗，質(zhì)量要求是不一樣的黄琼。包括時間，資源整慎，需求易變程度，復(fù)用程度和穩(wěn)定性围苫，人員素質(zhì)裤园，決策層的關(guān)注度等。很多時候是不能強求的……既不能向臟亂差隨便妥協(xié)剂府，也不能把自己項目搞成分析癱瘓拧揽。
熟練了解常見的幾種設(shè)計模式是必要的，這是一種工作語言，總不能同事說：“用策略模式吧”淤袜，然后你不知道這是什么東西痒谴。浪費大家的時間。設(shè)計模式可以起到便于溝通的作用铡羡，交流成本有時是很高的积蔚，尤其在程序員之間。
不是解決任何問題都要從頭做起烦周。往往我們更愿意復(fù)用以前使用過的解決方案尽爆。
（二）
好的，我們接著說說創(chuàng)建型模式读慎、結(jié)構(gòu)型模式和行為型模式底下都有些什么——
創(chuàng)建型模式用來處理對象的創(chuàng)建過程漱贱，主要包含以下5種設(shè)計模式：
?工廠方法模式（Factory Method Pattern）
?抽象工廠模式（Abstract Factory Pattern）
?建造者模式（Builder Pattern搜索），將一個復(fù)雜的構(gòu)建過程與其表示細節(jié)相分離夭委，使得相同的構(gòu)建過程可以創(chuàng)建不同的表示幅狮。
?原型模式（Prototype Pattern），通過拷貝原型創(chuàng)建新的對象株灸。
?單例模式（Singleton Pattern）崇摄，保證一個類只有一個實例。
結(jié)構(gòu)型模式用來處理類或者對象的組合蚂且，主要包含以下7種設(shè)計模式：
?適配器模式（Adapter Pattern）配猫，使得原本由于接口不兼容而不能一起工作的那些類 可以一起工作。
?橋接模式（Bridge Pattern）杏死，兩個維度獨立變化泵肄，依賴方式實現(xiàn)抽象與實現(xiàn)分離：需要一個作為橋接的接口/抽象類，多個角度的實現(xiàn)類依賴注入到抽象類淑翼，使它們在抽象層建立一個關(guān)聯(lián)關(guān)系腐巢。
?組合模式（Composite Pattern），用戶對單個對象和組合對象的使用具有一致性的統(tǒng)一接口玄括。
?裝飾者模式（Decorator Pattern）冯丙，保持接口，增強性能遭京；修飾類繼承被修飾對象的抽象父類胃惜，依賴被修飾對象的實例（被修飾對象依賴注入），以實現(xiàn)接口擴展哪雕。
?外觀模式（Facade Pattern）船殉，在客戶端和復(fù)雜系統(tǒng)之間再加一層，這一次將調(diào)用順序斯嚎、依賴關(guān)系等處理好利虫。即封裝底層實現(xiàn)挨厚，隱藏系統(tǒng)的復(fù)雜性，并向客戶端提供了一個客戶端可以訪問系統(tǒng)的高層接口糠惫。
?享元模式（Flyweight Pattern）疫剃，享元工廠類控制；HashMap實現(xiàn)緩沖池重用現(xiàn)有的同類對象硼讽，如果未找到匹配的對象巢价，則創(chuàng)建新對象。
?代理模式（Proxy Pattern）理郑，為其他對象提供一種代理以控制對這個對象的訪問：增加中間層（代理層）蹄溉，代理類與底層實現(xiàn)類實現(xiàn)共同接口，并創(chuàng)建底層實現(xiàn)類對象（底層實現(xiàn)類對象依賴注入代理類）您炉，以便向外界提供功能接口柒爵。
行為型模式用來對類或?qū)ο笤鯓咏换ズ驮鯓臃峙渎氊?zé)進行描述，主要包含以下11種設(shè)計模式：
?責(zé)任鏈模式（Chain of Responsibility Pattern）赚爵，攔截的類都實現(xiàn)統(tǒng)一接口棉胀，每個接收者都包含對下一個接收者的引用。將這些對象連接成一條鏈冀膝，并且沿著這條鏈傳遞請求唁奢，直到有對象處理它為止。
?命令模式（Command Pattern）窝剖，將"行為請求者"與"行為實現(xiàn)者"解耦：調(diào)用者依賴命令麻掸，命令依賴接收者，調(diào)用者Invoker→命令Command→接收者Receiver赐纱。
?解釋器模式（Interpreter Pattern）脊奋，給定一個語言，定義它的文法表示疙描，并定義一個解釋器诚隙，這個解釋器使用該標識來解釋語言中的句子。
?迭代器模式（Iterator Pattern）起胰，集合中含有迭代器：分離了集合對象的遍歷行為久又，抽象出一個迭代器類來負責(zé)，無須暴露該對象的內(nèi)部表示效五。
?中介者模式（Mediator Pattern）地消，對象與對象之間存在大量的關(guān)聯(lián)關(guān)系，將對象之間的通信關(guān)聯(lián)關(guān)系封裝到一個中介類中單獨處理畏妖，從而使其耦合松散犯建，可以獨立地改變它們之間的交互。
?備忘錄模式（Memento Pattern）瓜客，通過一個備忘錄類專門存儲對象狀態(tài)。客戶通過備忘錄管理類管理備忘錄類谱仪。
?觀察者模式（Observer Pattern）玻熙，一對多的依賴關(guān)系，在觀察目標類里有一個 ArrayList 存放觀察者們疯攒。當(dāng)觀察目標對象的狀態(tài)發(fā)生改變嗦随，所有依賴于它的觀察者都將得到通知，使這些觀察者能夠自動更新（即使用推送方式）敬尺。
?狀態(tài)模式（State Pattern）枚尼，狀態(tài)對象依賴注入到context對象，context對象根據(jù)它的狀態(tài)改變而改變它的相關(guān)行為(可通過調(diào)用內(nèi)部的狀態(tài)對象實現(xiàn)相應(yīng)的具體行為)砂吞。
?策略模式（Strategy Pattern）署恍，策略對象依賴注入到context對象，context對象根據(jù)它的策略改變而改變它的相關(guān)行為(可通過調(diào)用內(nèi)部的策略對象實現(xiàn)相應(yīng)的具體策略行為)蜻直。
?模板方法模式（Template Method Pattern）盯质，將這些通用算法抽象出來，在一個抽象類中公開定義了執(zhí)行它的方法的方式/模板概而。它的子類可以按需要重寫方法實現(xiàn)呼巷，但調(diào)用將以抽象類中定義的方式進行。
?訪問者模式（Visitor Pattern）赎瑰，
（三）
在知乎上看到一個回答王悍，寫的特別棒。為了方便大家閱讀燈餐曼，我在這貼出來压储，侵刪。
問題：如何正確地使用設(shè)計模式晋辆？
作者：kidneyball
鏈接：https://www.zhihu.com/question/23757906/answer/25616658
來源：知乎
著作權(quán)歸作者所有渠脉。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處瓶佳。
首先離題一下說點虛的其實GoF的《設(shè)計模式》一書芋膘，一共有三個層面的內(nèi)容:
1、指出編程開發(fā)活動中存在模式霸饲，提出總結(jié)設(shè)計模式需要關(guān)注的四要素 "名稱-問題-解決方案-效果“ 为朋，并給出描述一套模式的格式模板。
2厚脉、提出了面向?qū)ο箝_發(fā)中”針對接口編程優(yōu)于針對實現(xiàn)編程”习寸，”組合優(yōu)于繼承”的總體設(shè)計思路 。
3傻工、選取了現(xiàn)實開發(fā)中基于上述設(shè)計思路所形成的23種常見設(shè)計模式作為例子詳細描述雖然第3點包括的多個具體的設(shè)計模式實例占據(jù)了最多的篇幅霞溪，但事實上第1,2點才是綱孵滞。實際上《設(shè)計模式》一書最劃時代的意義，在于第1點鸯匹。在此之后坊饶，出現(xiàn)了以設(shè)計模式的格式來組織內(nèi)容的《分析模式》，《企業(yè)架構(gòu)模式》殴蓬，《企業(yè)集成模式》匿级，《xUnit測試模式》，《重構(gòu)》等等質(zhì)量頗高的書籍染厅。
在書中有一段我認為非常重要但很容易被忽略的話：
本書中涉及的設(shè)計模式并不描述新的或未經(jīng)證實的設(shè)計痘绎，我們只收錄那些在不同系統(tǒng)中多次使用過的成功設(shè)計。這些設(shè)計的絕大部分以往并無文本記錄肖粮，它們或是來源于面向?qū)ο笤O(shè)計者圈子里的非正式交流孤页，或是來源于某些成功的面向?qū)ο笙到y(tǒng)的某些部分，但對設(shè)計新手來說尿赚，這些東西是很難學(xué)得到的散庶。盡管這些設(shè)計不包括新的思路，但我們用一種新的凌净、便于理解的方式將其展現(xiàn)給讀者悲龟，即：具有統(tǒng)一格式的、已分類編目的若干組設(shè)計模式冰寻。
這段話的關(guān)鍵是：
1须教、書中的模式不是作者的發(fā)明創(chuàng)造或獨門秘籍，而是早已存在并已經(jīng)廣泛使用的做法斩芭，只不過沒有被系統(tǒng)地加以記錄轻腺。換而言之，只要遵循某些原則划乖，這些所謂模式完全可能在無意識的狀態(tài)下自發(fā)出現(xiàn)在產(chǎn)品代碼中贬养。
2、這些模式在各種系統(tǒng)被多次使用琴庵。換而言之误算，你只要接觸足夠多的代碼，必然會大量接觸到這些模式的實際應(yīng)用迷殿。只不過在看過《設(shè)計模式》一書之前儿礼，你可能意識不到這是一個成體系的設(shè)計手段。
3庆寺、作者認為《設(shè)計模式》這本書的價值在于對設(shè)計模式進行了有效的組織和便于理解的描述蚊夫。換而言之，這本書的寫作出發(fā)點是”便于理解“懦尝，并且是面向”設(shè)計新手“的知纷。而不少初學(xué)者卻恰恰覺得這本書難以理解壤圃，這說明，作者已經(jīng)在保證準確性的前提下屈扎，選用了他們所認為最便于理解的描述埃唯。比本書描述更為顯淺的描述，很可能會犧牲準確性（不準確的描述對于新手來說是顯然是害處大于好處）鹰晨。當(dāng)然某些人認為是作者表達能力有限，這種事情無法求證止毕，但我傾向于前者模蜡。
現(xiàn)在開始正題，如何正確使用設(shè)計模式
準確來說扁凛，正確使用GoF的《設(shè)計模式》一書中所涉及的23種模式忍疾。但我們不妨先考慮一個比較容易回答的問題，如何避免不正確地使用設(shè)計模式谨朝。畢竟不正確地使用還不如不用卤妒，你在避免不正確使用的前提下慢慢用起來，就是正確使用了字币。
使用設(shè)計模式最常見走入歧途的做法是：你看了《設(shè)計模式》中某個具體模式则披，覺得似懂非懂，或者甚至根本沒看過原書洗出。然后去看了一些舉例子打比喻的”再談“士复，”妙解“，”大話“之類的東西翩活，覺得豁然開朗阱洪。之后在開發(fā)時發(fā)現(xiàn)某一處非常符合你對這個模式的理解，于是開始使用菠镇。這種做法用來練手可以（也就是你明知使用這個模式未必是一個好主意冗荸，只是為了嘗試在現(xiàn)實場景中去實現(xiàn)一下，練習(xí)代碼并不進入最終產(chǎn)品代碼）利耍，用來做真實的設(shè)計則往往謬以千里蚌本。
原因很簡單：設(shè)計模式是一種駕馭抽象概念的技術(shù)，而描述模式的標準格式里就包括了抽象描述堂竟，代碼示例和應(yīng)用場景魂毁。如果一個程序員根據(jù)這些信息還不能理解一個設(shè)計模式的話，說明他首先抽象思維尚不足以駕馭設(shè)計模式出嘹，其次在理解代碼和接觸應(yīng)用場景方面經(jīng)驗不足席楚。簡單來說，還未能達到“設(shè)計新手”的入門水平税稼。在這種狀態(tài)下勉強去使用設(shè)計模式烦秩，出問題是在所難免的垮斯。
因而得出第一點：如果你已經(jīng)看過某個設(shè)計模式的描述，要正確使用它的最基本前提是只祠，你能完全看懂GoF《設(shè)計模式》中對它的描述兜蠕。在此之前，只看抛寝，不用熊杨。看是指看該模式的原文描述或者具體代碼盗舰。特別地晶府，不建議通過一些類比具體生活例子的方式來理解設(shè)計模式。設(shè)計模式的寫作格式是經(jīng)過驗證钻趋，能有效地描述一個模式而又不失準確性的手段川陆。如果你無法理解，看實際生產(chǎn)代碼的應(yīng)用場景是唯一真正有效的方法（因為設(shè)計模式本身就是從具體代碼中總結(jié)出來的）蛮位。用類比的方法降低設(shè)計模式的抽象性來幫助了解沒有實質(zhì)的意義——即使你覺得自己懂了较沪，你的抽象思維和開發(fā)經(jīng)驗還未達到能正確使用這個模式的水平。
正如前面所言失仁，只要你對面向?qū)ο笠恍┗驹瓌t有充分的理解尸曼，你甚至可能在沒看過《設(shè)計模式》之前就開始使用某種模式了，如果你已經(jīng)達到這種程度自然能無壓力看懂描述陶因。退一步假如你還沒達到這種程度骡苞，既然《設(shè)計模式》中的模式非常常見，你只要有心多看代碼楷扬，在現(xiàn)有代碼中必然能接觸到解幽。通過實際應(yīng)用的代碼與書中的描述互相印證，要理解亦不難烘苹。再退一步躲株，假如你接觸的代碼就一直沒遇到 某個模式，你也一直無法自發(fā)理解某個模式镣衡，那么這個模式就對你沒用霜定，你沒必要一定要找機會用。
避免不正確使用的第二點是廊鸥，避免過度設(shè)計望浩。這里說的過度設(shè)計本質(zhì)上就是你為可能發(fā)生的變動支付了過多的復(fù)雜度代價。其實過度設(shè)計和設(shè)計模式?jīng)]有必然的關(guān)系惰说，只要你認定一個地方會變動磨德，你就會考慮是否應(yīng)該增加復(fù)雜度來換取靈活性。設(shè)計模式只不過針對某些具體場景提供了一些效率較高的以復(fù)雜度換靈活性的手段而已。避免過度設(shè)計的關(guān)鍵是典挑，你能正確評估未雨綢繆所引入的復(fù)雜度酥宴，相對于發(fā)生變動的可能性和破壞力，是否值得您觉。
正確評估變動的可能性和破壞力拙寡，只能依靠行業(yè)經(jīng)驗，屬于資歷問題琳水。如果你對當(dāng)前場景沒有足夠的經(jīng)驗進行評估肆糕，最好的辦法就是假定它不會頻繁變化，只采用普通的高內(nèi)聚低耦合策略在孝，而不需要增加額外的復(fù)雜度來提供靈活性擎宝。等到確認出現(xiàn)變化時，再進行重構(gòu)浑玛。
而對設(shè)計模式的認識可能會影響對復(fù)雜度的估計，不少設(shè)計模式的初學(xué)者很容易錯誤估計實現(xiàn)某個設(shè)計模式所帶來的復(fù)雜度噩咪，認為靈活性隨手可得顾彰。又或者下意識地尋找練手機會而忽略掉復(fù)雜性的代價。在假定程序員對某個設(shè)計模式已經(jīng)充分理解的前提下胃碾，我覺得評估復(fù)雜度時至少應(yīng)該考慮到這些因素：
1涨享、需要額外引入哪些新的概念。要明白一段代碼涉及的概念越多仆百，就越難理解厕隧。
2、設(shè)計模式自身的實現(xiàn)復(fù)雜度俄周。
3吁讨、一旦引入后，為了保持設(shè)計所帶來的靈活性峦朗，后續(xù)開發(fā)需要注意的地方建丧。是否能通過代碼層面的限制來保證靈活性不會被破壞。
4波势、團隊中其他人對這個設(shè)計模式的理解程度翎朱。
5、對排錯調(diào)試尺铣，代碼靜態(tài)分析可能造成的影響 （例如Observer模式和Visitor模式往往會打亂靜態(tài)分析拴曲，難以通過閱讀代碼確定執(zhí)行狀態(tài)）如果能夠大致準確地評估上述要素然后作出決定，我覺得即使變動最終沒有發(fā)生凛忿，也算是一個合格的設(shè)計決策澈灼。真正的難點在于評估變動，這只能靠經(jīng)驗侄非。還有就是每次做出設(shè)計決策后最好能跟蹤總結(jié)蕉汪，為下次決策積累經(jīng)驗流译。關(guān)于設(shè)計模式的使用暫時想到這些。
既然題目中提到了“設(shè)計模式的荼毒”者疤，這里也說說我認為《設(shè)計模式》一書中最大一處問題：一句看上去正確福澡，但被后來一些讀物誤解并放大，在實際執(zhí)行中造成最多問題的話：
命名一個新的模式增加了我們的設(shè)計詞匯驹马。設(shè)計模式允許我們在較高的抽象層次上進行設(shè)計革砸。基于一個模式詞匯表糯累，我們自己以及同事之間就可以討論模式并在編寫文檔時使用它們算利。模式名可以幫助我們思考，便于我們與其他人交流設(shè)計思想及設(shè)計結(jié)果泳姐。
這句對“模式名稱”要素的描述的話效拭，在很多后續(xù)書籍或文章中被引申為：設(shè)計模式的一個重要作用是為團隊提供了一套方便的交流手段∨置耄看上去非常正確缎患，例如，我可以對同事說阎肝，這里需要一個Adapter挤渔；或者在代碼中直接命名XXXApapter，同事們一看就知道這是什么了风题。交流變得非常方便——前提是判导，我們都看過《設(shè)計模式》并清楚關(guān)于這個設(shè)計模式的描述。使用設(shè)計模式進行交流的結(jié)果就是：了解某個設(shè)計模式的人跟不了解這個設(shè)計模式的人根本無法交流沛硅。
而交流在團隊中是一種非逞廴校基礎(chǔ)，不可或缺的東西稽鞭，進一步的結(jié)果就是鸟整，了解某個設(shè)計模式的人認為不了解這個設(shè)計模式的人達不到基礎(chǔ)水平。而按照前文的分析朦蕴，設(shè)計模式只不過是對已有開發(fā)手段的總結(jié)篮条，完全有可能出現(xiàn)某個人的能力已經(jīng)足夠自發(fā)使用設(shè)計模式，只不過因為沒認真看過《設(shè)計模式》這本書吩抓，而被認為達不到基礎(chǔ)水平涉茧。這造成了很多有一定編程能力的開發(fā)者對設(shè)計模式十分反感。
再一步引申的結(jié)果是疹娶，因為設(shè)計模式變成了一種鑒別是否具有基礎(chǔ)水平的手段伴栓，那么為了讓自己看起來有基礎(chǔ)以上水平，就必須要表現(xiàn)得懂設(shè)計模式——即使看不懂《設(shè)計模式》原文。這就給許多“大話”钳垮，“再談”讀物帶來了市場惑淳，進而造就了一大批不是從實際開發(fā)或閱讀代碼中理解設(shè)計模式，在實際應(yīng)用中錯漏百出的初學(xué)者饺窿。
