首先說設計模式六大法則：
1.單一原則（Single Responsibility Principle）：一個類只負責一項職責，儘量做到類的只有一個行爲原因引起變化；
a、業務對象（BO business object）、業務邏輯（BL business logic）拆分；
2.里氏替換原則（LSP liskov substitution principle）：子類可以擴展父類的功能，但不能改變原有父類的功能；
通俗來說在軟件裏，可以把子類都替換爲父類，程序的行爲沒有變化。
3.依賴倒置原則（dependence inversion principle）：面向接口編程；（通過接口作爲參數實現應用場景）抽象就是接口或者抽象類，細節就是實現類含義：
上層模塊不應該依賴下層模塊，兩者應依賴其抽象；
抽象不應該依賴細節，細節應該依賴抽象；
4.接口隔離（interface segregation principle）：建立單一接口；（擴展爲類也是一種接口，一切皆接口）
定義：
a.客戶端不應該依賴它不需要的接口；
b.類之間依賴關係應該建立在最小的接口上；
【接口的設計粒度越小，系統越靈活，但是靈活的同時結構複雜性提高，開發難度也會變大，維護性降低】
5.迪米特原則（law of demeter LOD）：最少知道原則，儘量降低類與類之間的耦合；
6.開閉原則（open closed principle）：對擴展是開放的，對修改是關閉的。允許新增，不允許修改。
1.簡單工廠模式
1 工廠模式的作用，爲什麼要用工廠模式？
工廠模式是爲了解耦：把對象的創建和使用的過程分開。就是Class A 想調用Class B,那麼只是調用B的方法，而至於B的實例化，就交給工廠類。
工廠模式可以降低代碼重複。如果創建B過程都很複雜，需要一定的代碼量，而且很多地方都要用到，那麼就會有很多的重複代碼。可以把這些創建對象B的代碼放到工廠裏統一管理。既減少了重複代碼，也方便以後對B的維護。
工廠模式可以減少錯誤，因爲工廠管理了對象的創建邏輯，使用者不需要知道具體的創建過程，只管使用即可，減少了使用者因爲創建邏輯導致的錯誤。
2.工廠模式的一些適用場景：
對象的創建過程/實例化準備工作很複雜，需要很多初始化參數，查詢數據庫等
類本身有好多子類，這些類的創建過程在業務中容易發生改變，或者對類的調用容易發生改變。
2工廠模式
簡單工廠模式是把返回對象的邏輯寫到了工廠裏，根據傳入參數的不同，返回不同的對象。工廠模式是創建很多工廠類，直接創建工廠對象，在根據工廠對象生成對象。
3抽象工廠模式
抽象工廠模式（Abstract Factory Pattern）是圍繞一個超級工廠創建其他工廠。該超級工廠又稱爲其他工廠的工廠。這種類型的設計模式屬於創建型模式，它提供了一種創建對象的最佳方式。
在抽象工廠模式中，接口是負責創建一個相關對象的工廠，不需要顯式指定它們的類。每個生成的工廠都能按照工廠模式提供對象。
介紹
意圖：提供一個創建一系列相關或相互依賴對象的接口，而無需指定它們具體的類。
主要解決：主要解決接口選擇的問題。
何時使用：系統的產品有多於一個的產品族，而系統只消費其中某一族的產品。
如何解決：在一個產品族裏面，定義多個產品。
關鍵代碼：在一個工廠裏聚合多個同類產品。
應用實例：工作了，爲了參加一些聚會，肯定有兩套或多套衣服吧，比如說有商務裝（成套，一系列具體產品）、時尚裝（成套，一系列具體產品），甚至對於一個家庭來說，可能有商務女裝、商務男裝、時尚女裝、時尚男裝，這些也都是成套的，即一系列具體產品。假設一種情況（現實中是不存在的，要不然，沒法進入共產主義了，但有利於說明抽象工廠模式），在您的家中，某一個衣櫃（具體工廠）只能存放某一種這樣的衣服（成套，一系列具體產品），每次拿這種成套的衣服時也自然要從這個衣櫃中取出了。用 OOP 的思想去理解，所有的衣櫃（具體工廠）都是衣櫃類的（抽象工廠）某一個，而每一件成套的衣服又包括具體的上衣（某一具體產品），褲子（某一具體產品），這些具體的上衣其實也都是上衣（抽象產品），具體的褲子也都是褲子（另一個抽象產品）。
優點：當一個產品族中的多個對象被設計成一起工作時，它能保證客戶端始終只使用同一個產品族中的對象。
缺點：產品族擴展非常困難，要增加一個系列的某一產品，既要在抽象的 Creator 里加代碼，又要在具體的裏面加代碼。
使用場景： 1、QQ 換皮膚，一整套一起換。 2、生成不同操作系統的程序。
注意事項：產品族難擴展，產品等級易擴展。
4原型模式
原型模式（Prototype Pattern）是用於創建重複的對象，同時又能保證性能。這種類型的設計模式屬於創建型模式，它提供了一種創建對象的最佳方式。
這種模式是實現了一個原型接口，該接口用於創建當前對象的克隆。當直接創建對象的代價比較大時，則採用這種模式。例如，一個對象需要在一個高代價的數據庫操作之後被創建。我們可以緩存該對象，在下一個請求時返回它的克隆，在需要的時候更新數據庫，以此來減少數據庫調用。
介紹
意圖：用原型實例指定創建對象的種類，並且通過拷貝這些原型創建新的對象。
主要解決：在運行期建立和刪除原型。
何時使用： 1、當一個系統應該獨立於它的產品創建，構成和表示時。 2、當要實例化的類是在運行時刻指定時，例如，通過動態裝載。 3、爲了避免創建一個與產品類層次平行的工廠類層次時。 4、當一個類的實例只能有幾個不同狀態組合中的一種時。建立相應數目的原型並克隆它們可能比每次用合適的狀態手工實例化該類更方便一些。
如何解決：利用已有的一個原型對象，快速地生成和原型對象一樣的實例。
關鍵代碼： 1、實現克隆操作，在 JAVA 繼承 Cloneable，重寫 clone()，在 .NET 中可以使用 Object 類的 MemberwiseClone() 方法來實現對象的淺拷貝或通過序列化的方式來實現深拷貝。 2、原型模式同樣用於隔離類對象的使用者和具體類型（易變類）之間的耦合關係，它同樣要求這些"易變類"擁有穩定的接口。
應用實例： 1、細胞分裂。 2、JAVA 中的 Object clone() 方法。
優點： 1、性能提高。 2、逃避構造函數的約束。
缺點： 1、配備克隆方法需要對類的功能進行通盤考慮，這對於全新的類不是很難，但對於已有的類不一定很容易，特別當一個類引用不支持串行化的間接對象，或者引用含有循環結構的時候。 2、必須實現 Cloneable 接口。
使用場景： 1、資源優化場景。 2、類初始化需要消化非常多的資源，這個資源包括數據、硬件資源等。 3、性能和安全要求的場景。 4、通過 new 產生一個對象需要非常繁瑣的數據準備或訪問權限，則可以使用原型模式。 5、一個對象多個修改者的場景。 6、一個對象需要提供給其他對象訪問，而且各個調用者可能都需要修改其值時，可以考慮使用原型模式拷貝多個對象供調用者使用。 7、在實際項目中，原型模式很少單獨出現，一般是和工廠方法模式一起出現，通過 clone 的方法創建一個對象，然後由工廠方法提供給調用者。原型模式已經與 Java 融爲渾然一體，大家可以隨手拿來使用。
注意事項：與通過對一個類進行實例化來構造新對象不同的是，原型模式是通過拷貝一個現有對象生成新對象的。淺拷貝實現 Cloneable，重寫，深拷貝是通過實現 Serializable 讀取二進制流。
5策略模式
在策略模式（Strategy Pattern）中，一個類的行爲或其算法可以在運行時更改。這種類型的設計模式屬於行爲型模式。
介紹
意圖：定義一系列的算法,把它們一個個封裝起來, 並且使它們可相互替換。
主要解決：在有多種算法相似的情況下，使用 if…else 所帶來的複雜和難以維護。
何時使用：一個系統有許多許多類，而區分它們的只是他們直接的行爲。
如何解決：將這些算法封裝成一個一個的類，任意地替換。
關鍵代碼：實現同一個接口。
應用實例： 1、諸葛亮的錦囊妙計，每一個錦囊就是一個策略。 2、旅行的出遊方式，選擇騎自行車、坐汽車，每一種旅行方式都是一個策略。 3、JAVA AWT 中的 LayoutManager。
優點： 1、算法可以自由切換。 2、避免使用多重條件判斷。 3、擴展性良好。
缺點： 1、策略類會增多。 2、所有策略類都需要對外暴露。
使用場景：
1、如果在一個系統裏面有許多類，它們之間的區別僅在於它們的行爲，那麼使用策略模式可以動態地讓一個對象在許多行爲中選擇一種行爲。
2、一個系統需要動態地在幾種算法中選擇一種。
3、如果一個對象有很多的行爲，如果不用恰當的模式，這些行爲就只好使用多重的條件選擇語句來實現。
注意事項：如果一個系統的策略多於四個，就需要考慮使用混合模式，解決策略類膨脹的問題。
6.裝飾者模式
裝飾器模式（Decorator Pattern）允許向一個現有的對象添加新的功能，同時又不改變其結構。這種類型的設計模式屬於結構型模式，它是作爲現有的類的一個包裝。
意圖：動態地給一個對象添加一些額外的職責。就增加功能來說，裝飾器模式相比生成子類更爲靈活。
主要解決：一般的，我們爲了擴展一個類經常使用繼承方式實現，由於繼承爲類引入靜態特徵，並且隨着擴展功能的增多，子類會很膨脹。
何時使用：在不想增加很多子類的情況下擴展類。
如何解決：將具體功能職責劃分，同時繼承裝飾者模式。
關鍵代碼： 1、Component 類充當抽象角色，不應該具體實現。
2、修飾類引用和繼承 Component 類，具體擴展類重寫父類方法。
應用實例： 1、孫悟空有 72 變，當他變成"廟宇"後，他的根本還是一隻猴子，但是他又有了廟宇的功能。
2、不論一幅畫有沒有畫框都可以掛在牆上，但是通常都是有畫框的，並且實際上是畫框被掛在牆上。在掛在牆上之前，畫可以被蒙上玻璃，裝到框子裏；這時畫、玻璃和畫框形成了一個物體。
優點：裝飾類和被裝飾類可以獨立發展，不會相互耦合，裝飾模式是繼承的一個替代模式，裝飾模式可以動態擴展一個實現類的功能。
缺點：多層裝飾比較複雜。
使用場景： 1、擴展一個類的功能。 2、動態增加功能，動態撤銷。
注意事項：可代替繼承。
7建造者模式
建造者模式（Builder Pattern）使用多個簡單的對象一步一步構建成一個複雜的對象。這種類型的設計模式屬於創建型模式，它提供了一種創建對象的最佳方式。
一個 Builder 類會一步一步構造最終的對象。該 Builder 類是獨立於其他對象的。
介紹
意圖：將一個複雜的構建與其表示相分離，使得同樣的構建過程可以創建不同的表示。
主要解決：主要解決在軟件系統中，有時候面臨着"一個複雜對象"的創建工作，其通常由各個部分的子對象用一定的算法構成；由於需求的變化，這個複雜對象的各個部分經常面臨着劇烈的變化，但是將它們組合在一起的算法卻相對穩定。
何時使用：一些基本部件不會變，而其組合經常變化的時候。
如何解決：將變與不變分離開。
關鍵代碼：建造者：創建和提供實例，導演：管理建造出來的實例的依賴關係。
應用實例： 1、去肯德基，漢堡、可樂、薯條、炸雞翅等是不變的，而其組合是經常變化的，生成出所謂的"套餐"。 2、JAVA 中的 StringBuilder。
優點： 1、建造者獨立，易擴展。 2、便於控制細節風險。
缺點： 1、產品必須有共同點，範圍有限制。 2、如內部變化複雜，會有很多的建造類。
使用場景： 1、需要生成的對象具有複雜的內部結構。 2、需要生成的對象內部屬性本身相互依賴。
注意事項：與工廠模式的區別是：建造者模式更加關注與零件裝配的順序。
8適配器模式
適配器模式（Adapter Pattern）是作爲兩個不兼容的接口之間的橋樑。這種類型的設計模式屬於結構型模式，它結合了兩個獨立接口的功能。
這種模式涉及到一個單一的類，該類負責加入獨立的或不兼容的接口功能。舉個真實的例子，讀卡器是作爲內存卡和筆記本之間的適配器。您將內存卡插入讀卡器，再將讀卡器插入筆記本，這樣就可以通過筆記本來讀取內存卡。
意圖：將一個類的接口轉換成客戶希望的另外一個接口。適配器模式使得原本由於接口不兼容而不能一起工作的那些類可以一起工作。
主要解決：主要解決在軟件系統中，常常要將一些"現存的對象"放到新的環境中，而新環境要求的接口是現對象不能滿足的。
何時使用： 1、系統需要使用現有的類，而此類的接口不符合系統的需要。 2、想要建立一個可以重複使用的類，用於與一些彼此之間沒有太大關聯的一些類，包括一些可能在將來引進的類一起工作，這些源類不一定有一致的接口。 3、通過接口轉換，將一個類插入另一個類系中。（比如老虎和飛禽，現在多了一個飛虎，在不增加實體的需求下，增加一個適配器，在裏面包容一個虎對象，實現飛的接口。）
如何解決：繼承或依賴（推薦）。
關鍵代碼：適配器繼承或依賴已有的對象，實現想要的目標接口。
應用實例： 1、美國電器 110V，中國 220V，就要有一個適配器將 110V 轉化爲 220V。 2、JAVA JDK 1.1 提供了 Enumeration 接口，而在 1.2 中提供了 Iterator 接口，想要使用 1.2 的 JDK，則要將以前系統的 Enumeration 接口轉化爲 Iterator 接口，這時就需要適配器模式。 3、在 LINUX 上運行 WINDOWS 程序。 4、JAVA 中的 jdbc。
優點： 1、可以讓任何兩個沒有關聯的類一起運行。 2、提高了類的複用。 3、增加了類的透明度。 4、靈活性好。
缺點： 1、過多地使用適配器，會讓系統非常零亂，不易整體進行把握。比如，明明看到調用的是 A 接口，其實內部被適配成了 B 接口的實現，一個系統如果太多出現這種情況，無異於一場災難。因此如果不是很有必要，可以不使用適配器，而是直接對系統進行重構。 2.由於 JAVA 至多繼承一個類，所以至多隻能適配一個適配者類，而且目標類必須是抽象類。
使用場景：有動機地修改一個正常運行的系統的接口，這時應該考慮使用適配器模式。
注意事項：適配器不是在詳細設計時添加的，而是解決正在服役的項目的問題。