https://blog.csdn.net/ljh0302/article/details/81562415
設計模式一套被反覆使用，多數人知曉的代碼設計經驗的總結，實現可重用代碼，使代碼更容易被理解，保證代碼可靠性。
總體來說，設計模式分爲三大類：
創建型模式（五種）：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式
結構型模式（七種）：適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式
行爲型模式（十一種）：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解釋器模式。
常見的設計模式介紹：
1、單例模式
意圖：保證一個類僅有一個實例，並提供一個訪問它的全局訪問點。
主要解決：一個全局使用的類頻繁地創建與銷燬。
何時使用：當您想控制實例數目，節省系統資源的時候。
如何解決：判斷系統是否已經有這個單例，如果有則返回，如果沒有則創建。
關鍵代碼：構造函數是私有的。
應用實例： 1、一個黨只能有一個書記。 2、Windows 是多進程多線程的，在操作一個文件的時候，就不可避免地出現多個進程或線程同時操作一個文件的現象，所以所有文件的處理必須通過唯一的實例來進行。 3、一些設備管理器常常設計爲單例模式，比如一個電腦有兩臺打印機，在輸出的時候就要處理不能兩臺打印機打印同一個文件。
優點： 1、在內存裏只有一個實例，減少了內存的開銷，尤其是頻繁的創建和銷燬實例（比如管理學院首頁頁面緩存）。 2、避免對資源的多重佔用（比如寫文件操作）。
缺點：沒有接口，不能繼承，與單一職責原則衝突，一個類應該只關心內部邏輯，而不關心外面怎麼樣來實例化。
使用場景： 1、要求生產唯一序列號。 2、WEB 中的計數器，不用每次刷新都在數據庫里加一次，用單例先緩存起來。 3、創建的一個對象需要消耗的資源過多，比如 I/O 與數據庫的連接等。
注意事項：getInstance() 方法中需要使用同步鎖 synchronized (Singleton.class) 防止多線程同時進入造成 instance 被多次實例化。
2、工廠模式
在工廠模式中，我們在創建對象時不會對客戶端暴露創建邏輯，並且是通過使用一個共同的接口來指向新創建的對象。
意圖：定義一個創建對象的接口，讓其子類自己決定實例化哪一個工廠類，工廠模式使其創建過程延遲到子類進行。
主要解決：主要解決接口選擇的問題。
何時使用：我們明確地計劃不同條件下創建不同實例時。
如何解決：讓其子類實現工廠接口，返回的也是一個抽象的產品。
關鍵代碼：創建過程在其子類執行。
3、抽象工廠模式
抽象工廠模式（Abstract Factory Pattern）是圍繞一個超級工廠創建其他工廠。該超級工廠又稱爲其他工廠的工廠。這種類型的設計模式屬於創建型模式，它提供了一種創建對象的最佳方式。
在抽象工廠模式中，接口是負責創建一個相關對象的工廠，不需要顯式指定它們的類。每個生成的工廠都能按照工廠模式提供對象。
意圖：提供一個創建一系列相關或相互依賴對象的接口，而無需指定它們具體的類。
主要解決：主要解決接口選擇的問題。
何時使用：系統的產品有多於一個的產品族，而系統只消費其中某一族的產品。
如何解決：在一個產品族裏面，定義多個產品。
關鍵代碼：在一個工廠裏聚合多個同類產品。
4、觀察者模式
當對象間存在一對多關係時，則使用觀察者模式（Observer Pattern）。比如，當一個對象被修改時，則會自動通知它的依賴對象。觀察者模式屬於行爲型模式。
意圖：定義對象間的一種一對多的依賴關係，當一個對象的狀態發生改變時，所有依賴於它的對象都得到通知並被自動更新。
主要解決：一個對象狀態改變給其他對象通知的問題，而且要考慮到易用和低耦合，保證高度的協作。
何時使用：一個對象（目標對象）的狀態發生改變，所有的依賴對象（觀察者對象）都將得到通知，進行廣播通知。
如何解決：使用面向對象技術，可以將這種依賴關係弱化。
關鍵代碼：在抽象類裏有一個 ArrayList 存放觀察者們。
————————————————
版權聲明：本文爲CSDN博主「ljh0302」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/ljh0302/article/details/81562415
單例模式： 保證一個類只有一個實例 並且提供一個訪問該實例的全局訪問點
應用場景：比如說任務管理器，回收站
優點：由於單例模式只生成一個實例，減少了系統性能的開銷
單例模式可以再系統設置全局的訪問點，優化共享資源訪問
餓漢式：
懶漢式：
工廠模式：
簡單工廠模式：
工廠方法模式
抽象工廠模式：圍繞着一個超級工廠生產其他工廠該超級工廠又被稱爲其他工廠的工廠
你說一說OOP的設計模式的五項原則
參考回答：
1、單一職責原則
單一職責有2個含義，一個是避免相同的職責分散到不同的類中，另一個是避免一個類承擔太多職責。減少類的耦合，提高類的複用性。
2、接口隔離原則
表明客戶端不應該被強迫實現一些他們不會使用的接口，應該把胖接口中額方法分組，然後用多個接口代替它，每個接口服務於一個子模塊。簡單說，就是使用多個專門的接口比使用單個接口好很多。
該原則觀點如下：
1）一個類對另外一個類的依賴性應當是建立在最小的接口上
2）客戶端程序不應該依賴它不需要的接口方法。
3、開放-封閉原則
open模塊的行爲必須是開放的、支持擴展的，而不是僵化的。
closed在對模塊的功能進行擴展時，不應該影響或大規模影響已有的程序模塊。一句話概括：一個模塊在擴展性方面應該是開放的而在更改性方面應該是封閉的。
核心思想就是對抽象編程，而不對具體編程。
4、替換原則
子類型必須能夠替換掉他們的父類型、並出現在父類能夠出現的任何地方。
主要針對繼承的設計原則
1）父類的方法都要在子類中實現或者重寫，並且派生類只實現其抽象類中生命的方法，而不應當給出多餘的,方法定義或實現。
2）在客戶端程序中只應該使用父類對象而不應當直接使用子類對象，這樣可以實現運行期間綁定。
5、依賴倒置原則
上層模塊不應該依賴於下層模塊，他們共同依賴於一個抽象，即：父類不能依賴子類，他們都要依賴抽象類。
抽象不能依賴於具體，具體應該要依賴於抽象。