共計 6541 個字符，預計需要花費 17 分鐘才能閱讀完成。

設計模式簡介

設計模式（Design pattern）代表了最佳的實踐，通常被有經驗的面向對象的軟件開發人員所采用。設計模式是軟件開發人員在軟件開發過程中面臨的一般問題的解決方案。這些解決方案是眾多軟件開發人員經過相當長的一段時間的試驗和錯誤總結出來的。
設計模式是一套被反復使用的、多數人知曉的、經過分類編目的、代碼設計經驗的總結。使用設計模式是為了重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。毫無疑問，設計模式于己于他人于系統都是多贏的，設計模式使代碼編制真正工程化，設計模式是軟件工程的基石，如同大廈的一塊塊磚石一樣。項目中合理地運用設計模式可以完美地解決很多問題，每種模式在現實中都有相應的原理來與之對應，每種模式都描述了一個在我們周圍不斷重復發生的問題，以及該問題的核心解決方案，這也是設計模式能被廣泛應用的原因。

設計模式的類型

設計模式的六大原則

1、開閉原則（Open Close Principle）

開閉原則的意思是： 對擴展開放，對修改關閉 。在程序需要進行拓展的時候，不能去修改原有的代碼，實現一個熱插拔的效果。簡言之，是為了使程序的擴展性好，易于維護和升級。想要達到這樣的效果，我們需要使用接口和抽象類，后面的具體設計中我們會提到這點。

2、里氏代換原則（Liskov Substitution Principle）

里氏代換原則是面向對象設計的基本原則之一。里氏代換原則中說，任何基類可以出現的地方，子類一定可以出現。LSP 是繼承復用的基石，只有當派生類可以替換掉基類，且軟件單位的功能不受到影響時，基類才能真正被復用，而派生類也能夠在基類的基礎上增加新的行為。里氏代換原則是對開閉原則的補充。實現開閉原則的關鍵步驟就是抽象化，而基類與子類的繼承關系就是抽象化的具體實現，所以里氏代換原則是對實現抽象化的具體步驟的規范。

3、依賴倒轉原則（Dependence Inversion Principle）

這個原則是開閉原則的基礎，具體內容：針對接口編程，依賴于抽象而不依賴于具體。

4、接口隔離原則（Interface Segregation Principle）

這個原則的意思是：使用多個隔離的接口，比使用單個接口要好。它還有另外一個意思是：降低類之間的耦合度。由此可見，其實設計模式就是從大型軟件架構出發、便于升級和維護的軟件設計思想，它強調降低依賴，降低耦合。

5、迪米特法則，又稱最少知道原則（Demeter Principle）

最少知道原則是指：一個實體應當盡量少地與其他實體之間發生相互作用，使得系統功能模塊相對獨立。

6、合成復用原則（Composite Reuse Principle）

合成復用原則是指：盡量使用合成 / 聚合的方式，而不是使用繼承。

常用的設計模式（面試中可以直白解釋的設計模式）

工廠模式

工廠模式（Factory Pattern）是 Java 中最常用的設計模式之一。這種類型的設計模式屬于創建型模式，它提供了一種創建對象的最佳方式。

在工廠模式中，我們在創建對象時不會對客戶端暴露創建邏輯，并且是通過使用一個共同的接口來指向新創建的對象。

意圖： 定義一個創建對象的接口，讓其子類自己決定實例化哪一個工廠類，工廠模式使其創建過程延遲到子類進行。

主要解決： 主要解決接口選擇的問題。

何時使用： 我們明確地計劃不同條件下創建不同實例時。

如何解決： 讓其子類實現工廠接口，返回的也是一個抽象的產品。

關鍵代碼： 創建過程在其子類執行。

應用實例：?1、您需要一輛汽車，可以直接從工廠里面提貨，而不用去管這輛汽車是怎么做出來的，以及這個汽車里面的具體實現。2、Hibernate 換數據庫只需換方言和驅動就可以。

優點：?1、一個調用者想創建一個對象，只要知道其名稱就可以了。2、擴展性高，如果想增加一個產品，只要擴展一個工廠類就可以。3、屏蔽產品的具體實現，調用者只關心產品的接口。

缺點： 每次增加一個產品時，都需要增加一個具體類和對象實現工廠，使得系統中類的個數成倍增加，在一定程度上增加了系統的復雜度，同時也增加了系統具體類的依賴。這并不是什么好事。

使用場景：?1、日志記錄器：記錄可能記錄到本地硬盤、系統事件、遠程服務器等，用戶可以選擇記錄日志到什么地方。2、數據庫訪問，當用戶不知道最后系統采用哪一類數據庫，以及數據庫可能有變化時。3、設計一個連接服務器的框架，需要三個協議，”POP3″、”IMAP”、”HTTP”，可以把這三個作為產品類，共同實現一個接口。

注意事項： 作為一種創建類模式，在任何需要生成復雜對象的地方，都可以使用工廠方法模式。有一點需要注意的地方就是復雜對象適合使用工廠模式，而簡單對象，特別是只需要通過 new 就可以完成創建的對象，無需使用工廠模式。如果使用工廠模式，就需要引入一個工廠類，會增加系統的復雜度。

抽象工廠模式

抽象工廠模式（Abstract Factory Pattern）是圍繞一個超級工廠創建其他工廠。該超級工廠又稱為其他工廠的工廠。這種類型的設計模式屬于創建型模式，它提供了一種創建對象的最佳方式。

在抽象工廠模式中，接口是負責創建一個相關對象的工廠，不需要顯式指定它們的類。每個生成的工廠都能按照工廠模式提供對象。

意圖： 提供一個創建一系列相關或相互依賴對象的接口，而無需指定它們具體的類。

主要解決： 主要解決接口選擇的問題。

何時使用： 系統的產品有多于一個的產品族，而系統只消費其中某一族的產品。

如何解決： 在一個產品族里面，定義多個產品。

關鍵代碼： 在一個工廠里聚合多個同類產品。

應用實例： 工作了，為了參加一些聚會，肯定有兩套或多套衣服吧，比如說有商務裝（成套，一系列具體產品）、時尚裝（成套，一系列具體產品），甚至對于一個家庭來說，可能有商務女裝、商務男裝、時尚女裝、時尚男裝，這些也都是成套的，即一系列具體產品。假設一種情況（現實中是不存在的，但有利于說明抽象工廠模式），在您的家中，某一個衣柜（具體工廠）只能存放某一種這樣的衣服（成套，一系列具體產品），每次拿這種成套的衣服時也自然要從這個衣柜中取出了。用 OOP 的思想去理解，所有的衣柜（具體工廠）都是衣柜類的（抽象工廠）某一個，而每一件成套的衣服又包括具體的上衣（某一具體產品），褲子（某一具體產品），這些具體的上衣其實也都是上衣（抽象產品），具體的褲子也都是褲子（另一個抽象產品）。

優點： 當一個產品族中的多個對象被設計成一起工作時，它能保證客戶端始終只使用同一個產品族中的對象。

缺點： 產品族擴展非常困難，要增加一個系列的某一產品，既要在抽象的 Creator 里加代碼，又要在具體的里面加代碼。

使用場景：?1、QQ 換皮膚，一整套一起換。2、生成不同操作系統的程序。

注意事項： 產品族難擴展，產品等級易擴展。

單例模式

單例模式（Singleton Pattern）是 Java 中最簡單的設計模式之一。這種類型的設計模式屬于創建型模式，它提供了一種創建對象的最佳方式。

這種模式涉及到一個單一的類，該類負責創建自己的對象，同時確保只有單個對象被創建。這個類提供了一種訪問其唯一的對象的方式，可以直接訪問，不需要實例化該類的對象。

注意：

• 1、單例類只能有一個實例。
• 2、單例類必須自己創建自己的唯一實例。
• 3、單例類必須給所有其他對象提供這一實例。

意圖： 保證一個類僅有一個實例，并提供一個訪問它的全局訪問點。

主要解決： 一個全局使用的類頻繁地創建與銷毀。

何時使用： 當您想控制實例數目，節省系統資源的時候。

如何解決： 判斷系統是否已經有這個單例，如果有則返回，如果沒有則創建。

關鍵代碼： 構造函數是私有的。

應用實例：

• 1、一個班級只有一個班主任。
• 2、Windows 是多進程多線程的，在操作一個文件的時候，就不可避免地出現多個進程或線程同時操作一個文件的現象，所以所有文件的處理必須通過唯一的實例來進行。
• 3、一些設備管理器常常設計為單例模式，比如一個電腦有兩臺打印機，在輸出的時候就要處理不能兩臺打印機打印同一個文件。

優點：

• 1、在內存里只有一個實例，減少了內存的開銷，尤其是頻繁的創建和銷毀實例（比如管理學院首頁頁面緩存）。
• 2、避免對資源的多重占用（比如寫文件操作）。

缺點： 沒有接口，不能繼承，與單一職責原則沖突，一個類應該只關心內部邏輯，而不關心外面怎么樣來實例化。

使用場景：

• 1、要求生產唯一序列號。
• 2、WEB 中的計數器，不用每次刷新都在數據庫里加一次，用單例先緩存起來。
• 3、創建的一個對象需要消耗的資源過多，比如 I/O 與數據庫的連接等。

注意事項：getInstance() 方法中需要使用同步鎖 synchronized (Singleton.class) 防止多線程同時進入造成 instance 被多次實例化。

適配器模式

適配器模式（Adapter Pattern）是作為兩個不兼容的接口之間的橋梁。這種類型的設計模式屬于結構型模式，它結合了兩個獨立接口的功能。

這種模式涉及到一個單一的類，該類負責加入獨立的或不兼容的接口功能。舉個真實的例子，讀卡器是作為內存卡和筆記本之間的適配器。您將內存卡插入讀卡器，再將讀卡器插入筆記本，這樣就可以通過筆記本來讀取內存卡。

我們通過下面的實例來演示適配器模式的使用。其中，音頻播放器設備只能播放 mp3 文件，通過使用一個更高級的音頻播放器來播放 vlc 和 mp4 文件。

意圖： 將一個類的接口轉換成客戶希望的另外一個接口。適配器模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作。

主要解決： 主要解決在軟件系統中，常常要將一些 ” 現存的對象 ” 放到新的環境中，而新環境要求的接口是現對象不能滿足的。

何時使用：?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 至多繼承一個類，所以至多只能適配一個適配者類，而且目標類必須是抽象類。

使用場景： 有動機地修改一個正常運行的系統的接口，這時應該考慮使用適配器模式。

注意事項： 適配器不是在詳細設計時添加的，而是解決正在服役的項目的問題。

模板模式

在模板模式（Template Pattern）中，一個抽象類公開定義了執行它的方法的方式 / 模板。它的子類可以按需要重寫方法實現，但調用將以抽象類中定義的方式進行。這種類型的設計模式屬于行為型模式。

意圖： 定義一個操作中的算法的骨架，而將一些步驟延遲到子類中。模板方法使得子類可以不改變一個算法的結構即可重定義該算法的某些特定步驟。

主要解決： 一些方法通用，卻在每一個子類都重新寫了這一方法。

何時使用： 有一些通用的方法。

如何解決： 將這些通用算法抽象出來。

關鍵代碼： 在抽象類實現，其他步驟在子類實現。

應用實例：?1、在造房子的時候，地基、走線、水管都一樣，只有在建筑的后期才有加壁櫥加柵欄等差異。2、西游記里面菩薩定好的 81 難，這就是一個頂層的邏輯骨架。3、spring 中對 Hibernate 的支持，將一些已經定好的方法封裝起來，比如開啟事務、獲取 Session、關閉 Session 等，程序員不重復寫那些已經規范好的代碼，直接丟一個實體就可以保存。

優點：?1、封裝不變部分，擴展可變部分。2、提取公共代碼，便于維護。3、行為由父類控制，子類實現。

缺點： 每一個不同的實現都需要一個子類來實現，導致類的個數增加，使得系統更加龐大。

使用場景：?1、有多個子類共有的方法，且邏輯相同。2、重要的、復雜的方法，可以考慮作為模板方法。

注意事項： 為防止惡意操作，一般模板方法都加上 final 關鍵詞。

MVC 模式

MVC 模式代表 Model-View-Controller（模型 - 視圖 - 控制器）模式。這種模式用于應用程序的分層開發。

Model（模型） – 模型代表一個存取數據的對象或 JAVA POJO。它也可以帶有邏輯，在數據變化時更新控制器。

View（視圖） – 視圖代表模型包含的數據的可視化。

Controller（控制器） – 控制器作用于模型和視圖上。它控制數據流向模型對象，并在數據變化時更新視圖。它使視圖與模型分離開。

實現

我們將創建一個作為模型的 Student?對象。StudentView?是一個把學生詳細信息輸出到控制臺的視圖類，StudentController?是負責存儲數據到?Student?對象中的控制器類，并相應地更新視圖?StudentView。

• MVCPatternDemo，我們的演示類使用?StudentController?來演示 MVC 模式的用法。