一、創(chuàng)建型模式
1、抽象工廠模式(Abstract factory pattern): 提供一個(gè)接口, 用于創(chuàng)建相關(guān)或依賴對(duì)象的家族, 而不需要指定具體類.
2、生成器模式(Builder pattern): 使用生成器模式封裝一個(gè)產(chǎn)品的構(gòu)造過程, 并允許按步驟構(gòu)造. 將一個(gè)復(fù)雜對(duì)象的構(gòu)建與它的表示分離, 使得同樣的構(gòu)建過程可以創(chuàng)建不同的表示.
3、工廠模式(factory method pattern): 定義了一個(gè)創(chuàng)建對(duì)象的接口, 但由子類決定要實(shí)例化的類是哪一個(gè). 工廠方法讓類把實(shí)例化推遲到子類.
4、原型模式(prototype pattern): 當(dāng)創(chuàng)建給定類的實(shí)例過程很昂貴或很復(fù)雜時(shí), 就使用原形模式.
5、單例模式(Singleton pattern): 確保一個(gè)類只有一個(gè)實(shí)例, 并提供全局訪問點(diǎn).
餓漢式：
6、多例模式(Multition pattern): 在一個(gè)解決方案中結(jié)合兩個(gè)或多個(gè)模式, 以解決一般或重復(fù)發(fā)生的問題.

二、結(jié)構(gòu)型模式
1、適配器模式(Adapter pattern): 將一個(gè)類的接口, 轉(zhuǎn)換成客戶期望的另一個(gè)接口. 適配器讓原本接口不兼容的類可以合作無間. 對(duì)象適配器使用組合, 類適配器使用多重繼承.
2、橋接模式(Bridge pattern): 使用橋接模式通過將實(shí)現(xiàn)和抽象放在兩個(gè)不同的類層次中而使它們可以獨(dú)立改變.
3、組合模式(composite pattern): 允許你將對(duì)象組合成樹形結(jié)構(gòu)來表現(xiàn)"整體/部分"層次結(jié)構(gòu). 組合能讓客戶以一致的方式處理個(gè)別對(duì)象以及對(duì)象組合.
4、裝飾者模式(decorator pattern): 動(dòng)態(tài)地將責(zé)任附加到對(duì)象上, 若要擴(kuò)展功能, 裝飾者提供了比繼承更有彈性的替代方案.
5、外觀模式(facade pattern): 提供了一個(gè)統(tǒng)一的接口, 用來訪問子系統(tǒng)中的一群接口. 外觀定義了一個(gè)高層接口, 讓子系統(tǒng)更容易使用.
6、亨元模式(Flyweight Pattern): 如想讓某個(gè)類的一個(gè)實(shí)例能用來提供許多"虛擬實(shí)例", 就使用蠅量模式.
7、代理模式(Proxy pattern): 為另一個(gè)對(duì)象提供一個(gè)替身或占位符以控制對(duì)這個(gè)對(duì)象的訪問.

三、行為型模式
1、責(zé)任鏈模式(Chain of responsibility pattern): 通過責(zé)任鏈模式, 你可以為某個(gè)請(qǐng)求創(chuàng)建一個(gè)對(duì)象鏈. 每個(gè)對(duì)象依序檢查此請(qǐng)求并對(duì)其進(jìn)行處理或者將它傳給鏈中的下一個(gè)對(duì)象.
2、命令模式(Command pattern): 將"請(qǐng)求"封閉成對(duì)象, 以便使用不同的請(qǐng)求,隊(duì)列或者日志來參數(shù)化其他對(duì)象. 命令模式也支持可撤銷的操作.
3、解釋器模式(Interpreter pattern): 使用解釋器模式為語言創(chuàng)建解釋器.
4、迭代器模式(iterator pattern): 提供一種方法順序訪問一個(gè)聚合對(duì)象中的各個(gè)元素, 而又不暴露其內(nèi)部的表示.
5、中介者模式(Mediator pattern) : 使用中介者模式來集中相關(guān)對(duì)象之間復(fù)雜的溝通和控制方式.
6、備忘錄模式(Memento pattern): 當(dāng)你需要讓對(duì)象返回之前的狀態(tài)時(shí)(例如, 你的用戶請(qǐng)求"撤銷"), 你使用備忘錄模式.
7、觀察者模式(observer pattern): 在對(duì)象之間定義一對(duì)多的依賴, 這樣一來, 當(dāng)一個(gè)對(duì)象改變狀態(tài), 依賴它的對(duì)象都會(huì)收到通知, 并自動(dòng)更新.
8、狀態(tài)模式(State pattern): 允許對(duì)象在內(nèi)部狀態(tài)改變時(shí)改變它的行為, 對(duì)象看起來好象改了它的類.
9、策略模式(strategy pattern): 定義了算法族, 分別封閉起來, 讓它們之間可以互相替換, 此模式讓算法的變化獨(dú)立于使用算法的客戶.
10、模板方法模式(Template pattern): 在一個(gè)方法中定義一個(gè)算法的骨架, 而將一些步驟延遲到子類中. 模板方法使得子類可以在不改變算法結(jié)構(gòu)的情況下, 重新定義算法中的某些步驟.
11、訪問者模式(visitor pattern): 當(dāng)你想要為一個(gè)對(duì)象的組合增加新的能力, 且封裝并不重要時(shí), 就使用訪問者模式.

七大設(shè)計(jì)原則：開閉原則是目標(biāo)，里氏代換原則是基礎(chǔ)，依賴倒轉(zhuǎn)原則是手段
1、單一職責(zé)原則【SINGLE RESPONSIBILITY PRINCIPLE】：就一個(gè)類而言，應(yīng)該只有一個(gè)引起它變化的原因。
或者可以定義為：一個(gè)類只負(fù)責(zé)一個(gè)功能領(lǐng)域中的相應(yīng)職責(zé)。
在軟件系統(tǒng)中，一個(gè)類（大到模塊，小到方法）承擔(dān)的職責(zé)越多，它被復(fù)用的可能性就越小，而且一個(gè)類承擔(dān)的職責(zé)過多，就相當(dāng)于將這些職責(zé)耦合在一起，當(dāng)其中一個(gè)職責(zé)變化時(shí)，可能會(huì)影響其他職責(zé)的運(yùn)作，因此要將這些職責(zé)進(jìn)行分離，將不同的職責(zé)封裝在不同的類中，即將不同的變化原因封裝在不同的類中，如果多個(gè)職責(zé)總是同時(shí)發(fā)生改變則可將它們封裝在同一類中。
單一職責(zé)原則是實(shí)現(xiàn)高內(nèi)聚、低耦合的指導(dǎo)方針，它是最簡(jiǎn)單但又最難運(yùn)用的原則，需要設(shè)計(jì)人員發(fā)現(xiàn)類的不同職責(zé)并將其分離，而發(fā)現(xiàn)類的多重職責(zé)需要設(shè)計(jì)人員具有較強(qiáng)的分析設(shè)計(jì)能力和相關(guān)實(shí)踐經(jīng)驗(yàn)。

2、里氏代換原則【LISKOV SUBSTITUTION PRINCIPLE】：所有引用基類（父類）的地方必須能透明地使用其子類的對(duì)象。

• 1.子類可以實(shí)現(xiàn)父類的抽象方法，但不能覆蓋父類的非抽象方法。
• 2.子類中可以增加自己特有的方法。
• 3.當(dāng)子類的方法重寫父類的方法時(shí)，方法的前置條件（即方法的形參）要比父類方法的輸入?yún)?shù)更寬松。
• 4.當(dāng)子類的方法實(shí)現(xiàn)父類的抽象方法時(shí)，方法的后置條件（即方法的返回值）要比父類更嚴(yán)格。
  一句話總結(jié)：在程序中盡量使用基類類型來對(duì)對(duì)象進(jìn)行定義，而在運(yùn)行時(shí)再確定其子類類型，用子類對(duì)象來替換父類對(duì)象。

3、依賴倒轉(zhuǎn)原則【DEPENDENCE INVERSION PRINCIPLE】：高層模塊不應(yīng)該依賴低層模塊，二者都應(yīng)該依賴其抽象；抽象不應(yīng)該依賴細(xì)節(jié)；細(xì)節(jié)應(yīng)該依賴抽象。即針對(duì)接口編程，不要針對(duì)實(shí)現(xiàn)編程.

4、接口隔離原則【INTERFACE SEGREGATION PRINCIPLE】：建立單一接口，不要建立龐大臃腫的接口，盡量細(xì)化接口，接口中的方法盡量少。每一個(gè)接口應(yīng)該承擔(dān)一種相對(duì)獨(dú)立的角色，不干不該干的事，該干的事都要干。
(1) 當(dāng)把“接口”理解成一個(gè)類型所提供的所有方法特征的集合的時(shí)候，這就是一種邏輯上的概念，接口的劃分將直接帶來類型的劃分?？梢园呀涌诶斫獬山巧?，一個(gè)接口只能代表一個(gè)角色，每個(gè)角色都有它特定的一個(gè)接口，此時(shí)，這個(gè)原則可以叫做“角色隔離原則”。
(2) 如果把“接口”理解成狹義的特定語言的接口，那么ISP表達(dá)的意思是指接口僅僅提供客戶端需要的行為，客戶端不需要的行為則隱藏起來，應(yīng)當(dāng)為客戶端提供盡可能小的單獨(dú)的接口，而不要提供大的總接口。在面向?qū)ο缶幊陶Z言中，實(shí)現(xiàn)一個(gè)接口就需要實(shí)現(xiàn)該接口中定義的所有方法，因此大的總接口使用起來不一定很方便，為了使接口的職責(zé)單一，需要將大接口中的方法根據(jù)其職責(zé)不同分別放在不同的小接口中，以確保每個(gè)接口使用起來都較為方便，并都承擔(dān)某一單一角色。接口應(yīng)該盡量細(xì)化，同時(shí)接口中的方法應(yīng)該盡量少，每個(gè)接口中只包含一個(gè)客戶端（如子模塊或業(yè)務(wù)邏輯類）所需的方法即可，這種機(jī)制也稱為“定制服務(wù)”，即為不同的客戶端提供寬窄不同的接口。
接口太小會(huì)導(dǎo)致接口泛濫，接口太大會(huì)違背接口隔離原則。接口只包含為某一類用戶定制的方法即可。

5、迪米特法則【LOW OF DEMETER】：一個(gè)軟件實(shí)體應(yīng)當(dāng)盡可能少地與其他實(shí)體發(fā)生相互作用。
應(yīng)該盡量減少對(duì)象之間的交互，如果兩個(gè)對(duì)象之間不必彼此直接通信，那么這兩個(gè)對(duì)象就不應(yīng)當(dāng)發(fā)生任何直接的相互作用，如果其中的一個(gè)對(duì)象需要調(diào)用另一個(gè)對(duì)象的某一個(gè)方法的話，可以通過第三者轉(zhuǎn)發(fā)這個(gè)調(diào)用。簡(jiǎn)言之，就是通過引入一個(gè)合理的第三者來降低現(xiàn)有對(duì)象之間的耦合度。

6、開閉原則【OPEN CLOSE PRINCIPLE】：一個(gè)軟件實(shí)體如類、模塊和函數(shù)應(yīng)該對(duì)擴(kuò)展開放，對(duì)修改關(guān)閉.
抽象化是開閉原則的關(guān)鍵，可以為系統(tǒng)定義一個(gè)相對(duì)穩(wěn)定的抽象層，而將不同的實(shí)現(xiàn)行為移至具體的實(shí)現(xiàn)層中完成。在很多面向?qū)ο缶幊陶Z言中都提供了接口、抽象類等機(jī)制，可以通過它們定義系統(tǒng)的抽象層，再通過具體類來進(jìn)行擴(kuò)展。如果需要修改系統(tǒng)的行為，無須對(duì)抽象層進(jìn)行任何改動(dòng)，只需要增加新的具體類來實(shí)現(xiàn)新的業(yè)務(wù)功能即可，實(shí)現(xiàn)在不修改已有代碼的基礎(chǔ)上擴(kuò)展系統(tǒng)的功能，達(dá)到開閉原則的要求。

7、組合/聚合復(fù)用原則【Composition/Aggregation Reuse Principle(CARP) 】：盡量使用組合和聚合少使用繼承的關(guān)系來達(dá)到復(fù)用的原則.