簡述JAVA的幾種設(shè)計模式

JAVA中使用設(shè)計模式寫代碼能使代碼重用、直觀、可靠，共有23種設(shè)計模式，分別是：

我們提供的服務(wù)有：網(wǎng)站制作、做網(wǎng)站、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、南城ssl等。為上千家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的南城網(wǎng)站制作公司

創(chuàng)建型模式：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式；

結(jié)構(gòu)型模式：適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式；

行為型模式：策略模式、模板方法模式、觀察者模式、迭代子模式、責(zé)任鏈模式、命令模式、備忘錄模式、狀態(tài)模式、訪問者模式、中介者模式、解釋器模式，

java中幾種常見的設(shè)計模式

一共23種設(shè)計模式！

按照目的來分，設(shè)計模式可以分為創(chuàng)建型模式、結(jié)構(gòu)型模式和行為型模式。

創(chuàng)建型模式用來處理對象的創(chuàng)建過程；結(jié)構(gòu)型模式用來處理類或者對象的組合；行為型模式用來對類或?qū)ο笤鯓咏换ズ驮鯓臃峙渎氊?zé)進(jìn)行描述。

創(chuàng)建型模式用來處理對象的創(chuàng)建過程，主要包含以下5種設(shè)計模式：

? 工廠方法模式（Factory Method Pattern）

? 抽象工廠模式（Abstract Factory Pattern）

? 建造者模式（Builder Pattern）

? 原型模式（Prototype Pattern）

? 單例模式（Singleton Pattern）

結(jié)構(gòu)型模式用來處理類或者對象的組合，主要包含以下7種設(shè)計模式：

? 適配器模式（Adapter Pattern）

? 橋接模式（Bridge Pattern）

? 組合模式（Composite Pattern）

? 裝飾者模式（Decorator Pattern）

? 外觀模式（Facade Pattern）

? 享元模式（Flyweight Pattern）

? 代理模式（Proxy Pattern）

行為型模式用來對類或?qū)ο笤鯓咏换ズ驮鯓臃峙渎氊?zé)進(jìn)行描述，主要包含以下11種設(shè)計模式：

? 責(zé)任鏈模式（Chain of Responsibility Pattern）

? 命令模式（Command Pattern）

? 解釋器模式（Interpreter Pattern）

? 迭代器模式（Iterator Pattern）

? 中介者模式（Mediator Pattern）

? 備忘錄模式（Memento Pattern）

? 觀察者模式（Observer Pattern）

? 狀態(tài)模式（State Pattern）

? 策略模式（Strategy Pattern）

? 模板方法模式（Template Method Pattern）

? 訪問者模式（Visitor Pattern）

推薦你一本好書：《軟件秘笈：設(shè)計模式那點(diǎn)事》，里面講解的23中設(shè)計模式例子很生動，容易理解，還有JDK中設(shè)計模式應(yīng)用情況，看了收獲挺大的！百度里面搜“設(shè)計模式”，第一條中設(shè)計模式百度百科中就有首推該圖書，瀏覽量在20幾萬以上的，不會錯的。好東西大家一起分享！

祝你早日學(xué)會設(shè)計模式！

責(zé)任鏈模式（Chain of Responsibility）

描述 責(zé)任鏈模式（CoR）建議發(fā)出請求的對象與可能處理這個請求的對象集合之間是低耦合的（set of potential request handler objects） 在有不止一個對象可以處理或?qū)崿F(xiàn)（fulfill）客戶請求的時候 責(zé)任鏈模式（CoR）認(rèn)為順序地給每一個對象一次處理請求的機(jī)會 在這種情況下應(yīng)用責(zé)任鏈模式（CoR） 把每一個可能處理請求的對象以鏈表的形式組織起來 在鏈表中 每一個對象有一個指向下一個對象的指針(Pointer) 在鏈表中的第一個對象接受請求并且決定是否處理它 或者把它傳遞給下一個對象 請求一個接一個地遍歷（flow through）鏈表中的所有對象 直到請求被其中的一個對象處理或者因到達(dá)鏈表尾而沒有被處理 例如 如果A?〉B?〉C都可以處理請求 按照這個順序 A處理請求或者在不知B是否可以處理這個請求的情況下遞給B 接受到請求的B可以處理這個請求或者傳遞給C 當(dāng)C收到請求時 這個請求可以被C處理或者沒有經(jīng)過任何處理而結(jié)束 換句話說 提交的處理鏈表中的請求在到達(dá)鏈表尾前 可以不被任何處理 下面是責(zé)任鏈模式（CoR）一些重要的特征 （ ）可能處理請求的對象集合（set of potential request handler objects）以及它們在鏈表中的順序是由客戶端根據(jù)現(xiàn)應(yīng)用的狀態(tài)在運(yùn)行時動態(tài)決定的 （ ）客戶端根據(jù)現(xiàn)在的狀態(tài) 對于不同的請求類型 可以擁有不同的可能處理請求的對象集合（set of potential request handler objects） 一個處理請求的對象也可以根據(jù)客戶應(yīng)用的狀態(tài)和請求類型 把請求傳遞給不同的處理對象 為了使這些交互簡單 所有的可能處理請求的對象應(yīng)提供一致的接口 在JAVA中 不同處理對象可以實(shí)現(xiàn)一個共同的接口或者繼承同一個抽象的父類來實(shí)現(xiàn) （ ）客戶對象初始化請求 或者在不知道這些對象是否能處理這個請求的情況下初始化任何可能處理請求的對象 也就是說 客戶對象和在處理鏈表中的處理對象都不需要知道到底哪個對象去處理這個請求 （ ）請求不能保證被處理 也就是 在沒有處理的情況下 請求已經(jīng)到達(dá)了處理鏈表尾 下面的這個情景展示了一個購買請求傳遞到處理鏈表中 但是在到達(dá)鏈表尾時 并沒有被接受 例子 讓我們模擬一個在特定組織里的購買請求（PR）授權(quán)過程的應(yīng)用 通常 在確立訂單并發(fā)到賣方前 一個購買請求是需要不同的管理代表授權(quán)的 我們假定一個組織中在購買請求金額限制上分為四個授權(quán)管理層次 如下面的列表 Table : Levels of PR AuthorizationManagement Level Authorization LimitBranch Manager$ Regional Director$ Vice President$ President and COO$ 　 我們可以定義不同的類 來對應(yīng)上面列表中的不同管理層次 Listing : Classes Representing Different Management Levelsclass BranchManager {static double LIMIT = ;……}//End of classclass RegionalDirector {static double LIMIT = ;……}//End of classclass VicePresident {static double LIMIT = ;……}//End of classclass PresidentCOO {static double LIMIT = ;……}//End of class讓我們定義一個PurchaseRequest類 它代表購買請求 PurchaseRequestID:intdescription:Stringamount:doublegetAmount():double 　 Figure : PurchaseRequest Class RepresentationListing : PurchaseRequest Classclass PurchaseRequest {private int ID;private String description;private double amount;public PurchaseRequest(int id String desc double amt) {ID = id;description = desc;amount = amt;}public double getAmount() {return amount;}public String toString() {return ID + : + description;}}一個給定的購買請求（PR）被上面的管理代表所授權(quán)或處理 換句話說 代表不同管理層次的四個類都是處理給定購買請求的可能處理者（授權(quán)者） 因此 不建議PurchaseRequest實(shí)例榜定到任何的一個授權(quán)者 通過使用責(zé)任鏈模式（CoR） 實(shí)現(xiàn)了PurchaseRequest對象和可能授權(quán)請求的對象集合之間關(guān)聯(lián)的低耦合 利用責(zé)任鏈模式（CoR） 讓我們定義一個抽象類PRHandler 它定義這些可能授權(quán)購買請求對象的統(tǒng)一接口 Listing : Abstract PRHandler Classpublic abstract class PRHandler {private PRHandler nextHandler;private String handlerName;public PRHandler(String name) {handlerName = name;}public String getName() {return handlerName;}public abstract boolean authorize(PurchaseRequest request);public PRHandler getNextHandler() {return nextHandler;}public void setNextHandler(PRHandler handler) {nextHandler = handler;};} 　 Figure : Purchase Request Approver Hierarchy現(xiàn)在 每一個授權(quán)者被重新定義為抽象類PRHandler的子類 每一個授權(quán)對象把購買請求的金額和它所在的管理層次所授權(quán)的金額進(jìn)行比較 如果請求的金額小于授權(quán)的金額 它就可以授權(quán)購買 如果大于 它傳遞購買請求到鏈表中的下一個授權(quán)者 Listing : PRHandler Concrete Subclassesclass BranchManager extends PRHandler {static double LIMIT = ;public BranchManager(String name) {super(name);}public boolean authorize(PurchaseRequest request) {double amount = request getAmount();if (amount = LIMIT) {System out println( Branch Manager + getName() + has authorized the PR ? + request);return true;} else {//forward the request to the next handlerreturn getNextHandler() authorize(request);}}}//End of classclass RegionalDirector extends PRHandler {static double LIMIT = ;public RegionalDirector(String name) {super(name);}public boolean authorize(PurchaseRequest request) {double amount = request getAmount();if (amount = LIMIT) {System out println( Regional Director + getName() + has authorized the PR ? +request);return true;} else {//forward the request to the next handlerreturn getNextHandler() authorize(request);}}}//End of classclass VicePresident extends PRHandler {static double LIMIT = ;public VicePresident(String name) {super(name);}public boolean authorize(PurchaseRequest request) {double amount = request getAmount();if (amount = LIMIT) {System out println( V P + getName() + has authorized the PR ? + request);return true;} else {//forward the request to the next handlerreturn getNextHandler() authorize(request);}}}//End of classclass PresidentCOO extends PRHandler {static double LIMIT = ;public PresidentCOO(String name) {super(name);}public boolean authorize(PurchaseRequest request) {double amount = request getAmount();if (amount = LIMIT) {System out println( President COO + getName() + has authorized the PR ? + request);return true;} else {System out println( PR ? + request + couldn t be authorized \n + Executive Board needs to be + consulted for approval \n + reason: Amount too large );return false;}}}//End of class為了授權(quán)購買請求 客戶端需要 （ ）創(chuàng)建一個可能接受購買請求的授權(quán)對象集合 把他們按照授權(quán)金額升序進(jìn)行排列 使用setNextHandler(PRHandler)方法 連接每一個授權(quán)者 下面是可能的授權(quán)購買請求的授權(quán)鏈表: 　 Figure lishixinzhi/Article/program/Java/gj/201311/27453