java設計模式選擇

Java23種設計模式選擇

建造模式

　　1. 須要生成的產品對象有複雜的內部結構，每個內部成分自己能夠是對象，也能夠僅僅是一個對象（即產品對象）的一個組成部分。

　　2. 須要生成的產品對象的屬性相互依賴。建造模式能夠強制實行一種分步驟進行的建造過程，所以，若是產品對象的一個屬性必須在另外一個屬性被賦值以後才能夠被賦值，使用建造模式是一個很好的設計思想。

　　3. 在對象建立過程當中會使用到系統中的其餘一些對象，這些對象在產品對象的建立過程當中不易獲得。

抽象工廠模式

1.一個系統不該當依賴於產品類實例如何被建立、組合和表達的細節，這對於全部形態的工廠模式都是重要的。

　　2.這個系統的產品有多於一個的產品族，而系統只消費其中某一族的產品。

　　3.同屬於同一個產品族的產品是在一塊兒使用的，這一約束必須在系統的設計中體現出來。（好比：Intel主板必須使用Intel CPU、Intel芯片組）

　　4.系統提供一個產品類的庫，全部的產品以一樣的接口出現，從而使客戶端不依賴於實現。

 

原型模式

 使用原型模式建立對象比直接new一個對象在性能上要好的多，由於Object類的clone方法是一個本地方法，它直接操做內存中的二進制流，特別是複製大對象時，性能的差異很是明顯。

       使用原型模式的另外一個好處是簡化對象的建立，使得建立對象就像咱們在編輯文檔時的複製粘貼同樣簡單。

       由於以上優勢，因此在須要重複地建立類似對象時能夠考慮使用原型模式。好比須要在一個循環體內建立對象，假如對象建立過程比較複雜或者循環次數不少的話，使用原型模式不但能夠簡化建立過程，並且可使系統的總體性能提升不少。

 

單例模式

若是你的某個類在整個工程中只須要一個實例，就能夠用單例模式。好比你的工程須要讀取配置文件，通常狀況下你會寫個配置文件的類，而這個類在整個工程裏只須要new一次，全部調用者都是用同一個實例，那麼這個類就能夠採用單例模式

 

工廠方法模式

如組裝手機的代工廠。從手機原料工廠獲取外殼、顯示屏、主板、按鍵、電池等配件進行組裝。組裝手機工廠只負責手機的裝配，而不負責配件的生產，也不須要關心從手機原料工廠出來的配件是否改變，只要手機各個配置銜接的接口不變就行。好比原料工廠顯示屏從TFT 的換成了UFB的顯示屏，對於組裝手機的代工廠來講，只要接口沒變，只須要繼續裝配就行。

 

類適配器模式

當咱們要訪問的接口A中沒有咱們想要的方法 ，卻在另外一個接口B中發現了合適的方法，咱們又不能改變訪問接口A，在這種狀況下，咱們能夠定義一個適配器p來進行中轉，這個適配器p要實現咱們訪問的接口A，這樣咱們就能繼續訪問當前接口A中的方法（雖然它目前不是咱們的菜），而後再繼承接口B的實現類BB，這樣咱們能夠在適配器P中訪問接口B的方法了，這時咱們在適配器P中的接口A方法中直接引用BB中的合適方法，這樣就完成了一個簡單的類適配器。

 

 

橋樑模式

  若是一個系統須要在構件的抽象化角色和具體化角色之間增長更多的靈活性，避免在兩個層次之間創建靜態的聯繫。

   設計要求實現化角色的任何改變不該當影響客戶端，或者說實現化角色的改變對客戶端是徹底透明的。 

一個構件有多於一個的抽象化角色和實現化角色，系統須要它們之間進行動態耦合。

   雖然在系統中使用繼承是沒有問題的，可是因爲抽象化角色和具體化角色須要獨立變化，設計要求須要獨立管理這二者。 

 

裝飾器模式

裝飾模式(Decorate)也叫包裝模式(Wrapper)

裝飾模式下降系統的耦合度，能夠動態的增長或刪除對象的責任，並使得須要裝飾的具體構建類和具體裝飾類能夠獨立變化，以便增長新的具體構建類和具體裝飾類。

 

組合模式

 引用大話設計模式的片斷：「當發現需求中是體現部分與總體層次結構時，以及你但願用戶能夠忽略組合對象與單個對象的不一樣，統一地使用組合結構中的全部對象時，就應該考慮組合模式了。」

 

外觀模式（門面模式）

1- 爲複雜的模塊或子系統提供外界訪問的模塊；

2- 子系統相互獨立；

3- 在層析結構中，可使用外觀模式定義系統的每一層的入口。

 

 

享元模式

享元模式因爲其共享的特徵，能夠在任何「池」中操做，好比：線程池，數據庫鏈接池。

String類的設計也是享元模式。

 

代理模式

當咱們想要隱藏某個類時，能夠爲其提供代理類。

當一個類須要對不一樣的調用者提供不一樣的調用權限時，可使用代理類來實現（代理類不必定只有一個，咱們能夠創建多個代理類來實現，也能夠在一個代理類中金進行權限判斷來進行不一樣權限的功能調用）。

當咱們要擴展某個類的某個功能時，可使用代理模式，在代理類中進行簡單擴展（只針對簡單擴展，可在引用委託類的語句以前與以後進行）。

 

責任鏈模式

來考慮這樣一個功能:申請聚餐費用的管理。

　　不少公司都是這樣的福利，就是項目組或者是部門能夠向公司申請一些聚餐費用，用於組織項目組成員或者是部門成員進行聚餐活動。

　　申請聚餐費用的大體流程通常是：由申請人先填寫申請單，而後交給領導審批，若是申請批准下來，領導會通知申請人審批經過，而後申請人去財務領取費用，若是沒有批准下來，領導會通知申請人審批未經過，此事也就此做罷。

　　不一樣級別的領導，對於審批的額度是不同的，好比，項目經理只能審批500元之內的申請；部門經理能審批1000元之內的申請；而總經理能夠審覈任意額度的申請。

　　也就是說，當某人提出聚餐費用申請的請求後，該請求會經由項目經理、部門經理、總經理之中的某一位領導來進行相應的處理，可是提出申請的人並不知道最終會由誰來處理他的請求，通常申請人是把本身的申請提交給項目經理，或許最後是由總經理來處理他的請求。

　　

　　可使用責任鏈模式來實現上述功能：當某人提出聚餐費用申請的請求後，該請求會在 項目經理—〉部門經理—〉總經理 這樣一條領導處理鏈上進行傳遞，發出請求的人並不知道誰會來處理他的請求，每一個領導會根據本身的職責範圍，來判斷是處理請求仍是把請求交給更高級別的領導，只要有領導處理了，傳遞就結束了。

　　須要把每位領導的處理獨立出來，實現成單獨的職責處理對象，而後爲它們提供一個公共的、抽象的父職責對象，這樣就能夠在客戶端來動態地組合職責鏈，實現不一樣的功能要求了。

 

應用模式

在下面的狀況下應當考慮使用命令模式：

1）使用命令模式做爲"CallBack"在面向對象系統中的替代。"CallBack"講的即是先將一個函數登記上，而後在之後調用此函數。

2）須要在不一樣的時間指定請求、將請求排隊。一個命令對象和原先的請求發出者能夠有不一樣的生命期。換言之，原先的請求發出者可能已經不在了，而命令對象自己仍然是活動的。這時命令的接收者能夠是在本地，也能夠在網絡的另一個地址。命令對象能夠在串形化以後傳送到另一臺機器上去。

3）系統須要支持命令的撤消(undo)。命令對象能夠把狀態存儲起來，等到客戶端須要撤銷命令所產生的效果時，能夠調用undo()方法，把命令所產生的效果撤銷掉。命令對象還能夠提供redo()方法，以供客戶端在須要時，再從新實施命令效果。

4）若是一個系統要將系統中全部的數據更新到日誌裏，以便在系統崩潰時，能夠根據日誌裏讀回全部的數據更新命令，從新調用Execute()方法一條一條執行這些命令，從而恢復系統在崩潰前所作的數據更新。

 

命令模式

1.系統須要將請求調用者和請求接收者解耦，使得調用者和接收者不直接交互。

2.系統須要在不一樣的時間指定請求、將請求排隊和執行請求。

3.系統須要支持命令的撤銷(Undo)操做和恢復(Redo)操做。

4.系統須要將一組操做組合在一塊兒，即支持宏命令。

 

解釋器模式

1.某個簡單的語言須要解釋執行而且能夠將該語言中的語句表示爲一個抽象語法樹的時候.

2.在某些特定的領域出現不斷重複的問題時,能夠將該領域的問題轉化爲一種語法規則下的語句,並構建解釋器來解釋該語句.

 

 

迭代模式

1.訪問一個聚合對象的內容而無需暴露它的內部表示

2.支持對聚合對象的多種遍歷

3.爲遍歷不一樣的聚合結構提供一個統一的接口

 

 

中介者模式

在面向對象編程中，一個類必然會與其餘的類發生依賴關係，徹底獨立的類是沒有意義的。一個類同時依賴多個類的狀況也至關廣泛，既然存在這樣的狀況，說明，一對多的依賴關係有它的合理性，適當的使用中介者模式可使本來凌亂的對象關係清晰，可是若是濫用，則可能會帶來反的效果。通常來講，只有對於那種同事類之間是網狀結構的關係，纔會考慮使用中介者模式。能夠將網狀結構變爲星狀結構，使同事類之間的關係變的清晰一些。

       中介者模式是一種比較經常使用的模式，也是一種比較容易被濫用的模式。對於大多數的狀況，同事類之間的關係不會複雜到混亂不堪的網狀結構，所以，大多數狀況下，將對象間的依賴關係封裝的同事類內部就能夠的，沒有必要非引入中介者模式。濫用中介者模式，只會讓事情變的更復雜。

 

 

備忘錄模式

適合功能比較複雜的，但須要維護或記錄屬性歷史的功能。

數據庫事務管理中的回滾操做

文本編譯器中的Ctrl+z回退操做

 

觀察者模式

一、 對一個對象狀態的更新，須要其餘對象同步更新，並且其餘對象的數量動態可變。

二、 對象僅須要將本身的更新通知給其餘對象而不須要知道其餘對象的細節。

 

 

狀態模式

State模式在實際使用中比較多，適合"狀態的切換"。由於咱們常常會使用If elseif else 進行狀態切換， 若是針對狀態的這樣判斷切換反覆出現，咱們就要聯想到是否能夠採起State模式了。

不僅是根據狀態，也有根據屬性。若是某個對象的屬性不一樣，對象的行爲就不同，這點在數據庫系統中出現頻率比較高，咱們常常會在一個數據表的尾部，加上property屬性含義的字段，用以標識記錄中一些特殊性質的記錄，這種屬性的改變(切換)又是隨時可能發生的，就有可能要使用State。

在實際使用，相似開關同樣的狀態切換是不少的，但有時並非那麼明顯，取決於你的經驗和對系統的理解深度。

 

 

策略模式

許多相關的類僅僅是行爲有異。 「策略」提供了一種用多個行爲中的一個行爲來配置一個類的方法。即一個系統須要動態地在幾種算法中選擇一種。

當一個應用程序須要實現一種特定的服務或者功能，並且該程序有多種實現方式時使用。

一個類定義了多種行爲 , 而且這些行爲在這個類的操做中以多個條件語句的形式出現。將相關的條件分支移入它們各自的Strategy類中以代替這些條件語句。

 

 

模板方法模式

在某些類的算法中，用了相同的方法，形成代碼的重複。

控制子類擴展，子類必須遵照算法規則。

 在多個子類擁有相同的方法，而且這些方法邏輯相同時，能夠考慮使用模版方法模式。在程序的主框架相同，細節不一樣的場合下，也比較適合使用這種模式

 

訪問者模式

假如一個對象中存在着一些與本對象不相干（或者關係較弱）的操做，爲了不這些操做污染這個對象，則可使用訪問者模式來把這些操做封裝到訪問者中去。

假如一組對象中，存在着類似的操做，爲了不出現大量重複的代碼，也能夠將這些重複的操做封裝到訪問者中去。