Java「老兵」淺談源碼的七大設計模式

一個專業的程序員，老是把代碼的清晰性，兼容性，可移植性放在很重要的位置。他們老是經過定義大量的宏，來加強代碼的清晰度和可讀性，而又不增長編譯後的代碼長度和代碼的運行效率；他們老是在編碼的同時，就考慮到了之後的代碼維護和升級。甚至，只要分析百分之一的代碼後，你就會深入地體會到，什麼樣的代碼纔是一個專業的程序員寫的，什麼樣的代碼是一個業餘愛好者寫的。而這一點是任何沒有真正分析過標準代碼的人都沒法體會到的。

本文會介紹一些經典的設計模式思想：

經常使用設計模式

Proxy代理模式

代理模式：爲其餘對象提供一種代理以便控制對這個對象的訪問。

能夠詳細控制訪問某個類（對象）的方法，在調用這個方法前做的前置處理（統一的流程代碼放到代理中處理）。調用這個方法後作後置處理。

代理模式分類：

1.靜態代理（靜態定義代理類，咱們本身靜態定義的代理類。好比咱們本身定義一個明星的經紀人類）

2.動態代理（經過程序動態生成代理類，該代理類不是咱們本身定義的。而是由程序自動生成）比較重要！！

• JDK自帶的動態代理
• javaassist字節碼操做庫實現
• CGLIB
• ASM（底層使用指令，可維護性較差）

結構組成

代理模式主要涉及到三個角色：抽象角色、代理角色、真實角色（被代理的角色）。

抽象角色：聲明真實對象和代理對象的共同接口。即真實對象和代理對象共同要實現的行爲動做（比如房東和中介都要可以實現租房的行爲，都能把房子租給你）。

代理角色：代理角色內部含有對真實角色的引用，從而能夠去操做真實對象，同時代理對象提供與真實對象的接口，以便在任什麼時候候都能代替真實對象。同時，代理對象在執行真實對象的操做時，也能附加它本身的操做，至關於對真實對象的封裝

真實角色：代理角色所代理的對象，亦即咱們最終要引用的對象。

Factory工廠模式

工廠模式主要是爲建立對象提供過渡接口，以便將建立對象的具體過程屏蔽隔離起來，達到提升靈活性的目的。

工廠模式能夠分爲三類：

• 簡單工廠模式（Simple Factory）
• 工廠方法模式（Factory Method）
• 抽象工廠模式（Abstract Factory）

這三種模式從上到下逐步抽象，而且更具通常性。GOF在《設計模式》一書中將工廠模式分爲兩類：工廠方法模式（Factory Method）與抽象工廠模式（Abstract Factory）。將簡單工廠模式（Simple Factory）看爲工廠方法模式的一種特例，二者歸爲一類。

區別：

工廠方法模式：

• 一個抽象產品類，能夠派生出多個具體產品類。

• 一個抽象工廠類，能夠派生出多個具體工廠類。

每一個具體工廠類只能建立一個具體產品類的實例。

抽象工廠模式：

• 多個抽象產品類，每一個抽象產品類能夠派生出多個具體產品類。

• 一個抽象工廠類，能夠派生出多個具體工廠類。

• 每一個具體工廠類能夠建立多個具體產品類的實例。

區別：

工廠方法模式只有一個抽象產品類，而抽象工廠模式有多個。

工廠方法模式的具體工廠類只能建立一個具體產品類的實例，而抽象工廠模式能夠建立多個。

Singleton單例模式

• 單例模式只能有一個實例。
• 單例類必須建立本身的惟一實例。
• 單例類必須向其餘對象提供這一實例。

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

單例模式結構圖

單例模式（Singleton）是幾個建立模式中最對立的一個，它的主要特色不是根據用戶程序調用生成一個新的實例，而是控制某個類型的實例惟一性，經過上圖咱們知道它包含的角色只有一個，就是Singleton，它擁有一個私有構造函數，這確保用戶沒法經過new直接實例它。除此以外，該模式中包含一個靜態私有成員變量instance與靜態公有方法Instance()。Instance()方法負責檢驗並實例化本身，而後存儲在靜態成員變量中，以確保只有一個實例被建立。

使用Singleton模式有一個必要條件：在一個系統要求一個類只有一個實例時才應當使用單例模式。反之，若是一個類能夠有幾個實例共存，就不要使用單例模式。

不要使用單例模式存取全局變量。這違背了單例模式的用意，最好放到對應類的靜態成員中。

不要將數據庫鏈接作成單例，由於一個系統可能會與數據庫有多個鏈接，而且在有鏈接池的狀況下，應當儘量及時釋放鏈接。Singleton模式因爲使用靜態成員存儲類實例，因此可能會形成資源沒法及時釋放，帶來問題。

Delegate委派模式

委派模式（Delegate）是面向對象設計模式中經常使用的一種模式。這種模式的原理爲類B和類A是兩個互相沒有任何關係的類，B具備和A如出一轍的方法和屬性；而且調用B中的方法，屬性就是調用A中同名的方法和屬性。B好像就是一個受A受權委託的中介。第三方的代碼不須要知道A的存在，也不須要和A發生直接的聯繫，經過B就能夠直接使用A的功能，這樣既可以使用到A的各類公能，又可以很好的將A保護起來了。

委派模式的優勢:

• 單一一個類沒法表現複雜的設計
• 設計拆分
• 方便重用
• 相對獨立
• 功能定義清晰,行爲界面分離
• 鬆散耦合,容易擴展

strategy策略模式

定義一系列的算法,把每個算法封裝起來, 而且使它們可相互替換。本模式使得算法可獨立於使用它的客戶而變化。也稱爲政策模式(Policy)。（Definea family of algorithms,encapsulate each one, andmake them interchangeable. Strategy lets the algorithmvary independently from clients that use it. ）

策略模式把對象自己和運算規則區分開來，其功能很是強大，由於這個設計模式自己的核心思想就是面向對象編程的多形性的思想。

策略模式結構

當存在如下狀況時使用Strategy模式

• 許多相關的類僅僅是行爲有異。 「策略」提供了一種用多個行爲中的一個行爲來配置一個類的方法。即一個系統須要動態地在幾種算法中選擇一種。
• 須要使用一個算法的不一樣變體。例如，你可能會定義一些反映不一樣的空間 /時間權衡的算法。當這些變體實現爲一個算法的類層次時 ,可使用策略模式。
• 算法使用客戶不該該知道的數據。可以使用策略模式以免暴露覆雜的、與算法相關的數據結構。
• 一個類定義了多種行爲 , 而且這些行爲在這個類的操做中以多個條件語句的形式出現。將相關的條件分支移入它們各自的Strategy類中以代替這些條件語句。

Prototype原型模式

原型模式的主要思想是基於現有的對象克隆一個新的對象出來，通常是有對象的內部提供克隆的方法，經過該方法返回一個對象的副本，這種建立對象的方式，相比咱們以前說的幾類建立型模式仍是有區別的，以前的講述的工廠模式與抽象工廠都是經過工廠封裝具體的new操做的過程，返回一個新的對象，有的時候咱們經過這樣的建立工廠建立對象不值得，特別是如下的幾個場景的時候，可能使用原型模式更簡單也效率更高。

• 當一個系統應該獨立於它的產品建立、構成和表示時，要使用 Prototype模式
• 當要實例化的類是在運行時刻指定時，例如，經過動態裝載；
• 爲了不建立一個與產品類層次平行的工廠類層次時
• 當一個類的實例只能有幾個不一樣狀態組合中的一種時。創建相應數目的原型並克隆它們可能比每次用合適的狀態手工實例化該類更方便一些。（也就是當咱們在處理一些對象比較簡單，而且對象之間的區別很小，可能只是很固定的幾個屬性不一樣的時候，可能咱們使用原型模式更合適）。

原型模式結構

Template模板模式

• 模板方法模式是一種類的行爲型模式，在它的結構圖中只有類之間的繼承關係，沒有對象關聯關係。
• 板方法模式是基於繼承的代碼複用基本技術，模板方法模式的結構和用法也是面向對象設計的核心之一。在模板方法模式中，能夠將相同的代碼放在父類中，而將不一樣的方法實現放在不一樣的子類中。
• 在模板方法模式中，咱們須要準備一個抽象類，將部分邏輯以具體方法以及具體構造函數的形式實現，而後聲明一些抽象方法來讓子類實現剩餘的邏輯。不一樣的子類能夠以不一樣的方式實現這些抽象方法，從而對剩餘的邏輯有不一樣的實現，這就是模板方法模式的用意。模板方法模式體現了面向對象的諸多重要思想，是一種使用頻率較高的模式。

模板方法應用於下列狀況：

• 一次性實現一個算法的不變的部分，並將可變的行爲留給子類來實現。
• 各子類中公共的行爲應被提取出來並集中到一個公共父類中以免代碼重複。首先識別現有代碼中的不一樣之處，而且將不一樣之處分離爲新的操做。最後，用一個調用這些新的操做的模板方法來替換這些不一樣的代碼。全文中源碼分析能夠在羣619881427免費學習。感興趣的能夠加入進來。
• 控制子類擴展。模板方法只在特定點調用「 hook」操做 ，這樣就只容許在這些點進行擴展。

模板模式結構