設計模式博客

1. 如何學習JDK里的設計模式

最近在看JDK源碼，想在畢業前再好好提高一下寫代碼的能力，JDK是個優秀的源碼閱讀範本（spring的源碼也不錯）。JDK目錄下的src.zip里可以直接獲得源碼，我也push到了我Github的一個repo里。
網上搜了JDK設計模式，coolshell里也有一篇，不過我還是參照了Stackoverflow(原文鏈接)上的一個「Examples of GoF Design Patterns」的答復，詳細列舉了JDK里具體對應的類和函數，並結合了wiki上的許多整理好的優秀詞條內容。放到這個博客上，也方便自己深入學習，好好體會下設計模式內涵，光看書也會很枯燥，況且紙質的代碼看起來也不舒服。

2. 設計模式的相關圖書

《設計模式：可復用面向對象軟體的基礎》
作者：[美] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
出版社： 機械工業出版社副標題：可復用面向對象軟體的基礎譯者：李英軍、馬曉星、蔡敏、劉建中出版年：2000-9頁數：254定價：35.00元裝幀：平裝叢書：計算機科學叢書ISBN：9787111075752
《軟體秘笈：設計模式那點事》

作者：鄭阿奇
出版社：電子工業出版社
ISBN：9787121147821
出版時間：2011-11-01
叢書名：魅力·實踐·發現
版次：1
頁數：628
裝幀：平裝
所屬分類：圖書 > 計算機與互聯網 > 軟體工程及軟體方法學
附件：CD光碟
定價：￥87.00
內容簡介
本書在第1章軟體設計模式概述後，從第2章到第24章詮釋23個軟體設計模式。每一種都以一個生活故事開始，然後是模式定義、模式分析、模式實現、設計原則和使用場合。模式實現通過Eclipse中的Java工程展開，採用軟體編程詮釋設計模式故事中的情節和操作，非常有趣。在這個基礎上，總結該軟體設計模式的設計原則，最後提出使用場合。第25章對各種軟體設計模式進行系統總結，第26章是各種軟體設計模式綜合應用。
軟道語錄
設計模式
設計模式就是軟體設計中對於特定問題的習慣的，通用的解決模式。
《設計模式：基於C#的工程化實現及擴展》
作者：王翔
出版社：電子工業出版社
出版時間：2009-1-1
字數：850000
版次：1
頁數：652
開本：16開
印次：1
紙張：膠版紙
ISBN ：9787121075070
包裝：平裝
所屬分類：圖書 > 計算機/網路 > 程序設計 > C/C++/C#/VC/VC++
定價：￥98.00
專家推薦
本書立意明確，除了告訴你問題的類型與解法，還提供了可以立即演繹的程序代碼，相信這本案頭的工具書可以提供你一個不錯的思維模式，幫你造就有彈性、能擴充、易維護的軟體實體。
胡百敬微軟MVP，台灣恆逸資訊資深講師，「資料庫鐵人」
作者從GOF23種經典設計模式開始，帶你走進模式的失門，小到細粒度的基礎模式，大到粗粒度的架構模式，本書都做了詳盡的講解。如果您還在為了軟體需求的無盡變化而煩惱不斷，為了在軟體設計領域更上一層樓而苦苦思索，希望本書能夠帶給您一些啟發。
李會軍微軟MVP，博客園專家，IT168專欄作者
本書很有特色的地方，就是以工程角度來闡釋模式，相較純粹的模式之說，則更具普遍的下手角度，C#語言的高級特性結合設計模式的經典思想，兩者相得益彰。
王濤微軟MVP，博客園專家，《你必須知道的.NET》作者
內容簡介
本書基於C# 2.0的語法，試圖將GOF 23中的模式以一種可工程化的公共庫而非Example的方式呈現給讀者。內容包括以下7部分。
第1篇主要是概括性的介紹；第2篇創建型模式介紹通過將實例化職責委託他方對象的辦法，隔離客戶程序與具體類型實例化的依賴關系，保證客戶程序（或者外部系統）獲得期望具體類型實例的、同時不必發生直接的引用；第3篇結構型模式的重點在於如何通過靈活的體系組織不同的對象，並在此基礎上完成更為復雜的類型（或者類型系統），而參與組合的各類型之間始終保持盡量鬆散的結構關系；第4篇行為型模式關注於應用運行過程中演算法的提供和通信關系的梳理；第5篇主要介紹小顆粒度基礎模式和應用案例；第6篇主要介紹應用全局的模式化的實現方法，包括現2009年已經被普遍應用的N層模式及某些關鍵性框架產品採用的「微內核」模式；第7篇主要是一些針對Web和Web Service領域的模式設計技術。
本書主要針對對C#語言和.NET Framework平台有一定了解或有一定應用經驗的用戶，尤其適於那些希望運用模式技術在設計和開發方面多應對些挑戰的用戶。
作者簡介
王翔，軟體架構師，主要從事.NET、XML、公鑰基礎設施的開發。專注於數據（尤其是XML信息）的生產、加工、交換、提煉等過程。2009年參與了一系列有關應用密碼技術和PKI環境保護信息系統數據安全的項目。
最喜歡數學，平常案頭總是擺一本數學練習題。閑暇時間喜歡寫作，通過發表多種技術文章與國內外同行交流各種數據應用經驗。
項目間隙經常到各海濱城市徒步旅行、野外露營、出海航行、極限運動，這幾年烹飪也漸漸成為個人主要愛好。

3. zookeeper 用到哪些設計模式

ZooKeeper作為發現服務的問題

ZooKeeper(註：ZooKeeper是著名Hadoop的一個子項目，旨在解決大規模分
布式應用場景下，服務協調同步(Coordinate
Service)的問題;它可以為同在一個分布式系統中的其他服務提供：統一命名服務、配置管理、分布式鎖服務、集群管理等功能)是個偉大的開源項目，它
很成熟，有相當大的社區來支持它的發展，而且在生產環境得到了廣泛的使用;但是用它來做Service發現服務解決方案則是個錯誤。

在分布式系統領域有個著名的 CAP定理(C-
數據一致性;A-服務可用性;P-服務對網路分區故障的容錯性，這三個特性在任何分布式系統中不能同時滿足，最多同時滿足兩個);ZooKeeper是個

CP的，即任何時刻對ZooKeeper的訪問請求能得到一致的數據結果，同時系統對網路分割具備容錯性;但是它不能保證每次服務請求的可用性(註：也就

是在極端環境下，ZooKeeper可能會丟棄一些請求，消費者程序需要重新請求才能獲得結果)。但是別忘了，ZooKeeper是分布式協調服務，它的

職責是保證數據(註：配置數據，狀態數據)在其管轄下的所有服務之間保持同步、一致;所以就不難理解為什麼ZooKeeper被設計成CP而不是AP特性

的了，如果是AP的，那麼將會帶來恐怖的後果(註：ZooKeeper就像交叉路口的信號燈一樣，你能想像在交通要道突然信號燈失靈的情況嗎?)。而且，
作為ZooKeeper的核心實現演算法 Zab，就是解決了分布式系統下數據如何在多個服務之間保持同步問題的。

作為一個分布式協同服務，ZooKeeper非常好，但是對於Service發現服務來說就不合適了;因為對於Service發現服務來說就算
是
返回了包含不實的信息的結果也比什麼都不返回要好;再者，對於Service發現服務而言，寧可返回某服務5分鍾之前在哪幾個伺服器上可用的信息，也不能
因為暫時的網路故障而找不到可用的伺服器，而不返回任何結果。所以說，用ZooKeeper來做Service發現服務是肯定錯誤的，如果你這么用就慘
了!

而且更何況，如果被用作Service發現服務，ZooKeeper本身並沒有正確的處理網路分割的問題;而在雲端，網路分割問題跟其他類型的
故障一樣的確會發生;所以最好提前對這個問題做好100%的准備。就像 Jepsen在
ZooKeeper網站上發布的博客中所說：在ZooKeeper中，如果在同一個網路分區(partition)的節點數(nodes)數達不到
ZooKeeper選取Leader節點的逗法定人數地時，它們就會從ZooKeeper中斷開，當然同時也就不能提供Service發現服務了。

如果給ZooKeeper加上客戶端緩存(註：給ZooKeeper節點配上本地緩存)或者其他類似技術的話可以緩解ZooKeeper因為網
絡故障造成節點同步信息錯誤的問題。 Pinterest與 Airbnb公
司就使用了這個方法來防止ZooKeeper故障發生。這種方式可以從表面上解決這個問題，具體地說，當部分或者所有節點跟ZooKeeper斷開的情況
下，每個節點還可以從本地緩存中獲取到數據;但是，即便如此，ZooKeeper下所有節點不可能保證任何時候都能緩存所有的服務注冊信息。如果
ZooKeeper下所有節點都斷開了，或者集群中出現了網路分割的故障(註：由於交換機故障導致交換機底下的子網間不能互訪);那麼ZooKeeper

會將它們都從自己管理范圍中剔除出去，外界就不能訪問到這些節點了，即便這些節點本身是逗健康地的，可以正常提供服務的;所以導致到達這些節點的服務請求
被丟失了。(註：這也是為什麼ZooKeeper不滿足CAP中A的原因)

更深層次的原因是，ZooKeeper是按照CP原則構建的，也就是說它能保證每個節點的數據保持一致，而為ZooKeeper加上緩存的做法
的
目的是為了讓ZooKeeper變得更加可靠(available);但是，ZooKeeper設計的本意是保持節點的數據一致，也就是CP。所以，這樣

一來，你可能既得不到一個數據一致的(CP)也得不到一個高可用的(AP)的Service發現服務了;因為，這相當於你在一個已有的CP系統上強制栓了
一個AP的系統，這在本質上就行不通的!一個Service發現服務應該從一開始就被設計成高可用的才行!

如果拋開CAP原理不管，正確的設置與維護ZooKeeper服務就非常的困難;錯誤會 經常發生，
導致很多工程被建立只是為了減輕維護ZooKeeper的難度。這些錯誤不僅存在與客戶端而且還存在於ZooKeeper伺服器本身。Knewton平台
很多故障就是由於ZooKeeper使用不當而導致的。那些看似簡單的操作，如：正確的重建觀察者(reestablishing
watcher)、客戶端Session與異常的處理與在ZK窗口中管理內存都是非常容易導致ZooKeeper出錯的。同時，我們確實也遇到過
ZooKeeper的一些經典bug： ZooKeeper-1159 與 ZooKeeper-1576;
我們甚至在生產環境中遇到過ZooKeeper選舉Leader節點失敗的情況。這些問題之所以會出現，在於ZooKeeper需要管理與保障所管轄服務
群的Session與網路連接資源(註：這些資源的管理在分布式系統環境下是極其困難的);但是它不負責管理服務的發現，所以使用ZooKeeper當
Service發現服務得不償失。

做出正確的選擇：Eureka的成功

我們把Service發現服務從ZooKeeper切換到了Eureka平台，它是一個開
源的服務發現解決方案，由Netflix公司開發。(註：Eureka由兩個組件組成：Eureka伺服器和Eureka客戶端。Eureka伺服器用作

服務注冊伺服器。Eureka客戶端是一個java客戶端，用來簡化與伺服器的交互、作為輪詢負載均衡器，並提供服務的故障切換支持。)Eureka一開
始就被設計成高可用與可伸縮的Service發現服務，這兩個特點也是Netflix公司開發所有平台的兩個特色。(
他們都在討論Eureka)。自從切換工作開始到現在，我們實現了在生產環境中所有依賴於Eureka的產品沒有下線維護的記錄。我們也被告知過，在雲平
台做服務遷移註定要遇到失敗;但是我們從這個例子中得到的經驗是，一個優秀的Service發現服務在其中發揮了至關重要的作用!

首先，在Eureka平台中，如果某台伺服器宕機，Eureka不會有類似於ZooKeeper的選舉leader的過程;客戶端請求會自動切
換
到新的Eureka節點;當宕機的伺服器重新恢復後，Eureka會再次將其納入到伺服器集群管理之中;而對於它來說，所有要做的無非是同步一些新的服務

注冊信息而已。所以，再也不用擔心有逗掉隊地的伺服器恢復以後，會從Eureka伺服器集群中剔除出去的風險了。Eureka甚至被設計用來應付范圍更廣

的網路分割故障，並實現逗0地宕機維護需求。當網路分割故障發生時，每個Eureka節點，會持續的對外提供服務(註：ZooKeeper不會)：接收新
的服務注冊同時將它們提供給下游的服務發現請求。這樣一來，就可以實現在同一個子網中(same side of
partition)，新發布的服務仍然可以被發現與訪問。

但是，Eureka做到的不止這些。正常配置下，Eureka內置了心跳服務，用於淘汰一些逗瀕死地的伺服器;如果在Eureka中注冊的服
務，
它的逗心跳地變得遲緩時，Eureka會將其整個剔除出管理范圍(這點有點像ZooKeeper的做法)。這是個很好的功能，但是當網路分割故障發生時，

這也是非常危險的;因為，那些因為網路問題(註：心跳慢被剔除了)而被剔除出去的伺服器本身是很地健康逗的，只是因為網路分割故障把Eureka集群分割
成了獨立的子網而不能互訪而已。

幸運的是，Netflix考慮到了這個缺陷。如果Eureka服務節點在短時間里丟失了大量的心跳連接(註：可能發生了網路故障)，那麼這個
Eureka節點會進入地自我保護模式逗，同時保留那些逗心跳死亡逗的服務注冊信息不過期。此時，這個Eureka節點對於新的服務還能提供注冊服務，對

於地死亡逗的仍然保留，以防還有客戶端向其發起請求。當網路故障恢復後，這個Eureka節點會退出地自我保護模式逗。所以Eureka的哲學是，同時保
留地好數據逗與地壞數據逗總比丟掉任何地好數據逗要更好，所以這種模式在實踐中非常有效。

最後，Eureka還有客戶端緩存功能(註：Eureka分為客戶端程序與伺服器端程序兩個部分，客戶端程序負責向外提供注冊與發現服務接
口)。
所以即便Eureka集群中所有節點都失效，或者發生網路分割故障導致客戶端不能訪問任何一台Eureka伺服器;Eureka服務的消費者仍然可以通過

Eureka客戶端緩存來獲取現有的服務注冊信息。甚至最極端的環境下，所有正常的Eureka節點都不對請求產生相應，也沒有更好的伺服器解決方案來解
決這種問題時;得益於Eureka的客戶端緩存技術，消費者服務仍然可以通過Eureka客戶端查詢與獲取注冊服務信息，這點很重要。

Eureka的構架保證了它能夠成為Service發現服務。它相對與ZooKeeper來說剔除了Leader節點的選取或者事務日誌機制，
這
樣做有利於減少使用者維護的難度也保證了Eureka的在運行時的健壯性。而且Eureka就是為發現服務所設計的，它有獨立的客戶端程序庫，同時提供心
跳服務、服務健康監測、自動發布服務與自動刷新緩存的功能。但是，如果使用ZooKeeper你必須自己來實現這些功能。Eureka的所有庫都是開源
的，所有人都能看到與使用這些源代碼，這比那些只有一兩個人能看或者維護的客戶端庫要好。

維護Eureka伺服器也非常的簡單，比如，切換一個節點只需要在現有EIP下移除一個現有的節點然後添加一個新的就行。Eureka提供了一
個
web-based的圖形化的運維界面，在這個界面中可以查看Eureka所管理的注冊服務的運行狀態信息：是否健康，運行日誌等。Eureka甚至提供
了Restful-API介面，方便第三方程序集成Eureka的功能。

4. C#的設計模式有哪些

C#設計模式（1）－Simple Factory Pattern
C#設計模式（2）－Factory Method Pattern
C#設計模式（3）－Abstract Factory Pattern
C#設計模式（4）－Singleton Pattern
C#設計模式（5）－Builder Pattern
C#設計模式（6）－Prototype Pattern
C#設計模式（7）－Adapter Pattern
C#設計模式（8）－Composite Pattern
C#設計模式（9）－Decorator Pattern
C#設計模式（10）－Proxy Pattern
設計模式（11）－Flyweight Pattern
設計模式（12）－Facade Pattern
設計模式（13）－Bridge Pattern
設計模式（14）－Chain of Responsibility Pattern
設計模式（15）－Command Pattern
設計模式（16）－Observer Pattern
設計模式（17）－Visitor Pattern
設計模式（18）－Template Method Pattern
設計模式（19）－Strategy Pattern

在博客園人搜索C#設計模式，會有詳細的實踐教程，這個更有效！
學海無涯啊！

5. 設計模式都有哪些

總體來說設計模式分為三大類：

一、創建型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。

二、結構型模式，共七種：適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。

三、行為型模式，共十一種：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解釋器模式。

1、工廠方法模式：

定義一個用於創建對象的介面，讓子類決定實例化哪一個類。Factory Method 使一個類的實例化延遲到其子類。

工廠模式有一個問題就是，類的創建依賴工廠類，也就是說，如果想要拓展程序，必須對工廠類進行修改，這違背了閉包原則，所以，從設計角度考慮，有一定的問題，這就用到工廠方法模式。

創建一個工廠介面和創建多個工廠實現類，這樣一旦需要增加新的功能，直接增加新的工廠類就可以了，不需要修改之前的代碼。

2、抽象工廠模式：

提供一個創建一系列相關或相互依賴對象的介面，而無需指定它們具體的類。抽象工廠需要創建一些列產品，著重點在於"創建哪些"產品上，也就是說，如果你開發，你的主要任務是劃分不同差異的產品線，並且盡量保持每條產品線介面一致，從而可以從同一個抽象工廠繼承。

3、單例模式：

單例對象（Singleton）是一種常用的設計模式。在Java應用中，單例對象能保證在一個JVM中，該對象只有一個實例存在。這樣的模式有幾個好處：

（1）某些類創建比較頻繁，對於一些大型的對象，這是一筆很大的系統開銷。

（2）省去了new操作符，降低了系統內存的使用頻率，減輕GC壓力。

（3）有些類如交易所的核心交易引擎，控制著交易流程，如果該類可以創建多個的話，系統完全亂了。（比如一個軍隊出現了多個司令員同時指揮，肯定會亂成一團），所以只有使用單例模式，才能保證核心交易伺服器獨立控制整個流程。

4、建造者模式：

將一個復雜對象的構建與它的表示分離，使得同樣的構建過程可以創建不同的表示。

5、原型模式：

原型模式雖然是創建型的模式，但是與工程模式沒有關系，從名字即可看出，該模式的思想就是將一個對象作為原型，對其進行復制、克隆，產生一個和原對象類似的新對象。本小結會通過對象的復制，進行講解。在Java中，復制對象是通過clone()實現的，先創建一個原型類。

6、適配器模式：

適配器模式將某個類的介面轉換成客戶端期望的另一個介面表示，目的是消除由於介面不匹配所造成的類的兼容性問題。主要分為三類：類的適配器模式、對象的適配器模式、介面的適配器模式。

7、裝飾器模式：

顧名思義，裝飾模式就是給一個對象增加一些新的功能，而且是動態的，要求裝飾對象和被裝飾對象實現同一個介面，裝飾對象持有被裝飾對象的實例。

8、代理模式：

代理模式就是多一個代理類出來，替原對象進行一些操作，比如我們在租房子的時候回去找中介，為什麼呢？因為你對該地區房屋的信息掌握的不夠全面，希望找一個更熟悉的人去幫你做，此處的代理就是這個意思。

9、外觀模式：

外觀模式是為了解決類與類之家的依賴關系的，像spring一樣，可以將類和類之間的關系配置到配置文件中，而外觀模式就是將他們的關系放在一個Facade類中，降低了類類之間的耦合度，該模式中沒有涉及到介面。

10、橋接模式：

橋接模式就是把事物和其具體實現分開，使他們可以各自獨立的變化。橋接的用意是：將抽象化與實現化解耦，使得二者可以獨立變化，像我們常用的JDBC橋DriverManager一樣。

JDBC進行連接資料庫的時候，在各個資料庫之間進行切換，基本不需要動太多的代碼，甚至絲毫不用動，原因就是JDBC提供統一介面，每個資料庫提供各自的實現，用一個叫做資料庫驅動的程序來橋接就行了。

11、組合模式：

組合模式有時又叫部分-整體模式在處理類似樹形結構的問題時比較方便。使用場景：將多個對象組合在一起進行操作，常用於表示樹形結構中，例如二叉樹，數等。

12、享元模式：

享元模式的主要目的是實現對象的共享，即共享池，當系統中對象多的時候可以減少內存的開銷，通常與工廠模式一起使用。

13、策略模式：

策略模式定義了一系列演算法，並將每個演算法封裝起來，使其可以相互替換，且演算法的變化不會影響到使用演算法的客戶。需要設計一個介面，為一系列實現類提供統一的方法，多個實現類實現該介面，設計一個抽象類（可有可無，屬於輔助類），提供輔助函數。

14、模板方法模式：

一個抽象類中，有一個主方法，再定義1...n個方法，可以是抽象的，也可以是實際的方法，定義一個類，繼承該抽象類，重寫抽象方法，通過調用抽象類，實現對子類的調用。

15、觀察者模式：

觀察者模式很好理解，類似於郵件訂閱和RSS訂閱，當我們瀏覽一些博客或wiki時，經常會看到RSS圖標，就這的意思是，當你訂閱了該文章，如果後續有更新，會及時通知你。

其實，簡單來講就一句話：當一個對象變化時，其它依賴該對象的對象都會收到通知，並且隨著變化！對象之間是一種一對多的關系。

16、迭代子模式：

顧名思義，迭代器模式就是順序訪問聚集中的對象，一般來說，集合中非常常見，如果對集合類比較熟悉的話，理解本模式會十分輕松。這句話包含兩層意思：一是需要遍歷的對象，即聚集對象，二是迭代器對象，用於對聚集對象進行遍歷訪問。

17、責任鏈模式：

責任鏈模式，有多個對象，每個對象持有對下一個對象的引用，這樣就會形成一條鏈，請求在這條鏈上傳遞，直到某一對象決定處理該請求。但是發出者並不清楚到底最終那個對象會處理該請求，所以，責任鏈模式可以實現，在隱瞞客戶端的情況下，對系統進行動態的調整。

18、命令模式：

命令模式的目的就是達到命令的發出者和執行者之間解耦，實現請求和執行分開。

19、備忘錄模式：

主要目的是保存一個對象的某個狀態，以便在適當的時候恢復對象，個人覺得叫備份模式更形象些，通俗的講下：假設有原始類A，A中有各種屬性，A可以決定需要備份的屬性，備忘錄類B是用來存儲A的一些內部狀態，類C呢，就是一個用來存儲備忘錄的，且只能存儲，不能修改等操作。

20、狀態模式：

狀態模式在日常開發中用的挺多的，尤其是做網站的時候，我們有時希望根據對象的某一屬性，區別開他們的一些功能，比如說簡單的許可權控制等。

21、訪問者模式：

訪問者模式把數據結構和作用於結構上的操作解耦合，使得操作集合可相對自由地演化。訪問者模式適用於數據結構相對穩定演算法又易變化的系統。因為訪問者模式使得演算法操作增加變得容易。

若系統數據結構對象易於變化，經常有新的數據對象增加進來，則不適合使用訪問者模式。訪問者模式的優點是增加操作很容易，因為增加操作意味著增加新的訪問者。訪問者模式將有關行為集中到一個訪問者對象中，其改變不影響系統數據結構。其缺點就是增加新的數據結構很困難。

22、中介者模式：

中介者模式也是用來降低類類之間的耦合的，因為如果類類之間有依賴關系的話，不利於功能的拓展和維護，因為只要修改一個對象，其它關聯的對象都得進行修改。

如果使用中介者模式，只需關心和Mediator類的關系，具體類類之間的關系及調度交給Mediator就行，這有點像spring容器的作用。

23、解釋器模式：

解釋器模式一般主要應用在OOP開發中的編譯器的開發中，所以適用面比較窄。

(5)設計模式博客擴展閱讀：

介紹三本關於設計模式的書：

1、《設計模式：可復用面向對象軟體的基礎》

作者：[美] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

出版社： 機械工業出版社

2、《軟體秘笈：設計模式那點事》

作者：鄭阿奇

出版社：電子工業出版社

3、《設計模式：基於C#的工程化實現及擴展》

作者：王翔

出版社：電子工業出版社

6. 50分 .net架構師 必須要會全部的設計模式嗎，還需要會什麼

不一定啊，比較經典的幾個要回，單例模式。工廠模式。觀察者模式之類的，其實你只要有六七個模式能夠熟練運用就已經足夠了，有一本書寫的挺好我之前在看，就叫設計模式，裡面舉例都是三國啊水滸啊一些故事來講，挺逗的，涵蓋了所有設計模式，基於java的，可以看一看，不用java也能有很多收獲

7. 軟體設計模式主要有哪幾種

軟體設計模式主要有以下三大類共23種：

一、創建型模式：

1、工廠方法模式工廠方法模式的創建是因為簡單工廠模式有一個問題，在簡單工廠模式中類的創建依賴工廠類，如果想要拓展程序，必須對工廠類進行修改，這違背了開閉原則，所以就出現了工廠方法模式，只需要創建一個工廠介面和多個工廠實現類。

2、抽象工廠模式抽象工廠模式是提供一個創建一系列相關或相互依賴對象的介面，而無需指定它們具體的類。區別於工廠方法模式的地方，工廠方法模式是創建一個工廠，可以實現多種對象；而抽象工廠模式是提供一個抽象工廠介面，裡面定義多種工廠，每個工廠可以生產多種對象。

3、單例模式單例模式能保證一個類僅有一個實例，並提供一個訪問它的全局訪問點，同時在類內部創造單一對象，通過設置許可權，使類外部無法再創造對象。單例對象能保證在一個JVM中，該對象只有一個實例存在。

4、建造者模式建造者模式是將一個復雜的構建與其表示相分離，使得同樣的構建過程可以創建不同的表示。在程序當中就是將一些不會變的基本組件，通過builder來進行組合，構建復雜對象，實現分離。

5、原型模式：原型模式是用原型實例指定創建對象的種類，並且通過拷貝這些原型創建新的對象。其實就是將對象復制了一份並返還給調用者，對象需繼承Cloneable並重寫clone方法。原型模式的思想就是將一個對象作為原型，對其進行復制、克隆，產生一個和原對象類似的新對象。

二、結構型模式：

1、適配器模式適配器模式是使得原本由於介面不兼容而不能一起工作的那些類可以一起工作，銜接兩個不兼容、獨立的介面的功能，使得它們能夠一起工作，適配器起到中介的作用。

2、裝飾模式：裝飾器模式是動態地給一個對象添加一些額外的職責，給一個對象增加一些新的功能，要求裝飾對象和被裝飾對象實現同一個介面，裝飾對象持有被裝飾對象的實例。除了動態的增加，也可以動態的撤銷，要做到動態的形式，不可以用繼承實現，因為繼承是靜態的。

3、代理模式代理模式是為其他對象提供一種代理以控制對這個對象的訪問，也就是創建類的代理類，間接訪問被代理類的過程中，對其功能加以控制。

4、外觀模式外觀模式是為子系統中的一組介面提供一個一致的界面，外觀模式定義了一個高層介面，這個介面使得這一子系統更加容易使用。

5、橋接模式橋接模式是將抽象部分與實現部分分離，使它們都可以獨立的變化。橋接模式就是把事物和其具體實現分開，使他們可以各自獨立的變化（突然聯想到了mvc模式）。

6、組合模式：組合模式是將對象組合成樹形結構以表示"部分-整體"的層次結構，組合模式使得用戶對單個對象和組合對象的使用具有一致性。

7、享元模式：享元模式是運用共享技術有效地支持大量細粒度的對象。享元模式的主要目的是實現對象的共享，即共享池，當系統中對象多的時候可以減少內存的開銷，重用現有的同類對象，若未找到匹配的對象，則創建新對象，這樣可以減少對象的創建，降低系統內存，提高效率。

三、行為型模式：

1、策略模式：

策略模式是定義一系列的演算法,把它們一個個封裝起來, 並且使它們可相互替換，且演算法的變化不會影響到使用演算法的客戶。

2、模版方法模式：

模板方法模式是定義一個操作中的演算法的骨架，而將一些步驟延遲到子類中。該模式就是在一個抽象類中，有一個主方法，再定義1...n個方法，可以是抽象的，也可以是實際的方法，定義一個類，繼承該抽象類，重寫抽象方法，通過調用抽象類，實現對子類的調用。

模板方法使得子類可以不改變一個演算法的結構即可重定義該演算法的某些特定步驟，將一些固定步驟、固定邏輯的方法封裝成模板方法。調用模板方法即可完成那些特定的步驟。

3、觀察者模式：

觀察者模式是定義對象間的一種一對多的依賴關系，當一個對象的狀態發生改變時，所有依賴於它的對象都得到通知並被自動更新。

也就是當被觀察者狀態變化時，通知所有觀察者，這種依賴方式具有雙向性，在QQ郵箱中的郵件訂閱和RSS訂閱，當用戶瀏覽一些博客時，經常會看到RSS圖標，簡單來說就是當訂閱了該文章，如果後續有更新，會及時通知用戶。這種現象即是典型的觀察者模式。

4、迭代器模式：

迭代器模式是提供一種方法順序訪問一個聚合對象中各個元素, 而又無須暴露該對象的內部表示。

在Java當中，將聚合類中遍歷各個元素的行為分離出來，封裝成迭代器，讓迭代器來處理遍歷的任務；使簡化聚合類，同時又不暴露聚合類的內部，在我們經常使用的JDK中各個類也都是這些基本的東西。

5、責任鏈模式：

責任鏈模式是避免請求發送者與接收者耦合在一起，讓多個對象都有可能接收請求，將這些對象連接成一條鏈，並且沿著這條鏈傳遞請求，直到有對象處理它為止。有多個對象，每個對象持有對下一個對象的引用，這樣就會形成一條鏈，請求在這條鏈上傳遞，直到某一對象決定處理該請求。

6、命令模式：

命令模式是將一個請求封裝成一個對象，從而使發出者可以用不同的請求對客戶進行參數化。模式當中存在調用者、接收者、命令三個對象，實現請求和執行分開；調用者選擇命令發布，命令指定接收者。

7、備忘錄模式：

備忘錄模式是在不破壞封裝性的前提下，捕獲一個對象的內部狀態，並在該對象之外保存這個狀態。創建一個備忘錄類，用來存儲原始類的信息；同時創建備忘錄倉庫類，用來存儲備忘錄類，主要目的是保存一個對象的某個狀態，以便在適當的時候恢復對象，也就是做個備份。

8、狀態模式：

狀態模式是允許對象在內部狀態發生改變時改變它的行為。對象具有多種狀態，且每種狀態具有特定的行為。

9、訪問者模式：

訪問者模式主要是將數據結構與數據操作分離。在被訪問的類裡面加一個對外提供接待訪問者的介面，訪問者封裝了對被訪問者結構的一些雜亂操作，解耦結構與演算法，同時具有優秀的擴展性。通俗來講就是一種分離對象數據結構與行為的方法。

10、中介者模式：

中介者模式是用一個中介對象來封裝一系列的對象交互，中介者使各對象不需要顯式地相互引用，從而使其耦合鬆散，而且可以獨立地改變它們之間的交互。

11、解釋器模式：

解釋器模式是給定一個語言，定義它的文法表示，並定義一個解釋器，這個解釋器使用該標識來解釋語言中的句子，基本也就用在這個范圍內，適用面較窄，例如：正則表達式的解釋等。

(7)設計模式博客擴展閱讀：

軟體設計的概念以及意義：

軟體設計模式是對軟體設計經驗的總結，是對軟體設計中反復出現的設計問題的成功解決方案的描述。為了記錄這些成功的設計經驗並方便以後使用，軟體設計模式通常包含 4 個基本要素：模式名稱、問題、解決方案以及效果。

模式名稱實際上就是一個幫助記憶的名稱，是用於軟體設計的技術術語，有助於設計者之間的交流。

問題描述了設計者所面臨的設計場景，用於告訴設計者在什麼情況下使用該模式。

解決方案描述了設計的細節，通常會給出方案的原理圖示（例如 UML 的類圖，序列圖等，也可能是一些示意圖）及相關文字說明，如果可能，還會給出一些代碼實例，以便對解決方案的深入理解。

效果描述了設計方案的優勢和劣勢，這些效果通常面向軟體的質量屬性，例如，可擴展性、可復用性等。

軟體設計模式的重要意義在於設計復用。設計模式可以使設計者更加方便地借鑒或直接使用已經過證實的成功設計方案，而不必花費時間進行重復設計。一些設計模式甚至提供了顯示的類圖設計及代碼實例，為設計的文檔化及軟體的開發提供了直接的支持。

8. 設計模式：適配器模式和代理模式的區別

這是之前我的博客總結的：

Proxy，代理模式：為其他對象提供一種代理以控制對這個對象的訪問。
例如：經典的體現在Spring AOP切面中，Spring中利用了倆種代理類型。
其實，代理也分為靜態和動態，但是我們一般常用動態，因為靜態代理秀不起來

Adapter,適配器模式：將一類的介面轉換成客戶希望的另外一個介面，Adapter模式使得原本由於介面不兼容而不能一起工作那些類可以一起工作。
其中對象的適配器模式是各種結構型模式的起源，分為三種：類，對象，介面的適配器模式。

結一下三種適配器模式的應用場景：
類的適配器模式：當希望將一個類轉換成滿足另一個新介面的類時，可以使用類的適配器模式，創建一個新類，繼承原有的類，實現新的介面即可。
對象的適配器模式：當希望將一個對象轉換成滿足另一個新介面的對象時，可以創建一個Wrapper類，持有原類的一個實例，在Wrapper類的方法中，調用實例的方法就行。
介面的適配器模式：當不希望實現一個介面中所有的方法時，可以創建一個抽象類Wrapper，實現所有方法，我們寫別的類的時候，繼承抽象類即可。

區別：很明顯，適配器模式是因為新舊介面不一致導致出現了客戶端無法得到滿足的問題，但是，由於舊的介面是不能被完全重構掉的，因為我們還想使用實現了這個介面的一些服務。那麼為了使用以前實現舊介面的服務，我們就應該把新的介面轉換成舊介面。相比於適配器的應用場景，代理就不一樣了，雖然代理也同樣是增加了一層，但是，代理提供的介面和原本的介面是一樣的，代理模式的作用是不把實現直接暴露給client，而是通過代理這個層，代理能夠做一些處理。

9. Angularjs+SSH的設計模式是MVC還是屬於MVVM

後端吐html，前端用Angular當然抄是可以的，我最近做的項目就是這樣。

不要因為網上幾篇博客，就認為Angular一定要被用來開發SPA，後端一定要吐JSON。後端吐HTML利於搜索引擎優化，前端用Angular寫一個微型app處理些表單什麼的不行嗎？一定要把業務邏輯暴漏在js代碼里，然後用戶load頁面要先下載好幾百kb的script？在時間技術資源有限的情況下，一切的設計模式，架構，方法論，框架，庫的選擇和運用，到最終都是為了解決實際問題。

所以，你前端用MVVM模式，後端用MVC模式，整體上還是遵守了良好的系統架構，沒有必要因為概念的限制來拘束你的系統設計。

10. Python有設計模式么

單例模式：Python 的單例模式最好不要藉助類（在 Java 中藉助類是因為 Java 所有代碼都要寫在類中），而是通過一個模塊來實現。一個模塊的模塊內全局變數、模塊內全局函數，組合起來就是一個單例對象了。
模板方法模式：這個可以像其他語言一樣實現，但是如果要遵循鴨子類型原則的話，應該刪除公有的抽象父類（或介面），從而追求靈活性。
工廠方法模式、多例模式：這個也不用藉助類，直接寫一個全局函數作為工廠函數即可。因為 Python 中實例化是通過 call 類來完成的，現在改成 call 工廠函數，對客戶摳碼者是透明的。（從這點我表示理解 Python 沒有 new 操作符的好處了，使用通用的 call 定義，正交性極強）
裝飾器模式、代理模式：這個接觸過 Python 就不會不知道了，Python 內置的 decorator 語法如此著名。裝飾器模式和代理模式都可以通過這種方式完成。另外一種是對對象的裝飾或代理，這個也不需要按照契約編程的風格，讓代理對象實現被代理對象的抽象。一切動態代理，只需要通過重載屬性訪問操作符，神馬都簡單了（和 PHP 通過 __get、__set、__call 來實現動態代理很類似）。
原型模式：這個在 Python 中實現的不是那麼爽快，需要調用 來克隆原型對象。但是其實有另一種實現方式：之所以使用原型模式，是因為對象初始化需要較大開銷。我們只需要保存初始化的結果，並在產生新對象的時候賦予新對象即可。所以，通過元類控制對象被創建的過程，來實現原型模式，也是一種選擇。