委派模式：

　　委派模式不屬于23種設(shè)計模式, 主要角色有三種: 抽象任務(wù)角色, 委派者角色, 具體任務(wù)角色.實現(xiàn)層面上, 定義一個抽象接口, 它有若干實現(xiàn)類, 他們真正執(zhí)行業(yè)務(wù)方法, 這些子類是具體任務(wù)角色; 定義委派者角色也實現(xiàn)該接口, 但它負責(zé)在各個具體角色實例之間做出決策, 由它判斷并調(diào)用具體實現(xiàn)的方法.委派模式對外隱藏了具體實現(xiàn), 僅將委派者角色暴露給外部, 在spring中以 Delegate與 Dispatcher結(jié)尾的，都是委派模式。其實委派模式就是代理模式跟策略模式的一種特殊的組合情況。

應(yīng)用場景：不屬于 23 種設(shè)計模式之一，是面向?qū)ο笤O(shè)計模式中常用的一種模式。這種模式的原理為類 B和類 A 是兩個互相沒有任何關(guān)系的類，B 具有和 A 一模一樣的方法和屬性；并且調(diào)用 B 中的方法，屬性就是調(diào)用 A 中同名的方法和屬性。B 好像就是一個受 A 授權(quán)委托的中介。第三方的代碼不需要知道 A 的存在，也不需要和 A 發(fā)生直接的聯(lián)系，通過 B 就可以直接使用 A 的功能，這樣既能夠使用到 A 的各種功能，又能夠很好的將 A 保護起來了，一舉兩得。

意圖：

　　定義抽象接口的一個實現(xiàn)類, 他負責(zé)判斷和調(diào)用哪個實現(xiàn)類的實例。

優(yōu)點: 對內(nèi)隱藏實現(xiàn), 易于擴展; 簡化調(diào)用;

　　委派模式大量使用在spring,mybatis等開源框架中, 理解委派模式的實現(xiàn)原理可以更好理解這些框架源碼.委派模式的核心是委派類的實現(xiàn).

　　如Spring的DispatcherServlet.其實真的去執(zhí)行方法的人并不是這個 DispatcherServlet，而實他通過handle中預(yù)先加載了各個contriller中method對應(yīng)的URL，保存在內(nèi)存中，當(dāng)有請求過來，他拿到這個請求所對應(yīng)的 URL，然后去比較，找到對應(yīng)的就交給對應(yīng)的Method去執(zhí)行。

　　這里舉個簡單的例子，通過 Boss去交代一個任務(wù)給項目經(jīng)理， 項目經(jīng)理（Leader）自己不干活，但是他知道可以由誰去干這個活，結(jié)果分配到手底下的人去做。

　　先定義一個抽象類：

public interface ITarget {//具體需要誰去干，由子類(項目經(jīng)理)去決定// 需要怎么干，由員工定義void doing(String command);}

　　先來兩個員工(被委派者（Target))：

public class TargetA implements ITarget {@Overridepublic void doing(String command) {System.out.println("我是員工A，我現(xiàn)在開始干" + command + "工作");} } public class TargetB implements ITarget {@Overridepublic void doing(String command) {System.out.println("我是員工B，我現(xiàn)在開始干" + command + "工作");} }

　　項目經(jīng)理(委派者（Leader）)登場：

public class Leader implements ITarget {//作為委派者，他必須知道底下的人誰比較擅長干什么// 就好比DispatcherServlet 里面哪個handle保存了 controller跟URL的對應(yīng)關(guān)系一樣private Map<String,ITarget> targets = new HashMap<String,ITarget>();public Leader() {// 員工A適合干加密工作targets.put("加密",new TargetA());// 員工B 適合干登陸開發(fā)targets.put("登錄",new TargetB());}//項目經(jīng)理自己不干活public void doing(String command){targets.get(command).doing(command);}}

　　最后來個測試類，Boss 來發(fā)布任務(wù)了，這樣子項目經(jīng)理會委派底下的人去干活，而自己干了一下調(diào)度的活。

public class Boss {public static void main(String[] args) {//客戶請求（Boss）、委派者（Leader）、被委派者（Target）//委派者要持有被委派者的引用//代理模式注重的是過程， 委派模式注重的是結(jié)果//策略模式注重是可擴展（外部擴展），委派模式注重內(nèi)部的靈活和復(fù)用//委派的核心：就是分發(fā)、調(diào)度、派遣//委派模式：就是靜態(tài)代理和策略模式一種特殊的組合new Leader().doing("登錄");} }　

delegate委派模式和Proxy代理模式：

Proxy :譯為代理，主要使用場景：為簡化編程（或無法操作B）而把請求交給代理方（A），由代理方與被代理方進行通信，以完成請求。

Delegete : 譯為委托，主要使用場景：一件事情（或一個請求）對象本身不知道怎樣處理，對象把請求交給其它對象來做。

　　簡單來講，可以這么理解，代理是若干個對象實現(xiàn)了一個共同的接口，而委派只是說明一個對象引用了另一個對象，并不牽扯接口。

適配器模式：

　　適配器模式（Adapter Pattern）是作為兩個不兼容的接口之間的橋梁。這種類型的設(shè)計模式屬于結(jié)構(gòu)型模式，它結(jié)合了兩個獨立接口的功能。這種模式涉及到一個單一的類，該類負責(zé)加入獨立的或不兼容的接口功能。舉個真實的例子，讀卡器是作為內(nèi)存卡和筆記本之間的適配器。您將內(nèi)存卡插入讀卡器，再將讀卡器插入筆記本，這樣就可以通過筆記本來讀取內(nèi)存卡。

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

主要解決：主要解決在軟件系統(tǒng)中，常常要將一些"現(xiàn)存的對象"放到新的環(huán)境中，而新環(huán)境要求的接口是現(xiàn)對象不能滿足的。

何時使用： 1、系統(tǒng)需要使用現(xiàn)有的類，而此類的接口不符合系統(tǒng)的需要。 2、想要建立一個可以重復(fù)使用的類，用于與一些彼此之間沒有太大關(guān)聯(lián)的一些類，包括一些可能在將來引進的類一起工作，這些源類不一定有一致的接口。 3、通過接口轉(zhuǎn)換，將一個類插入另一個類系中。（比如老虎和飛禽，現(xiàn)在多了一個飛虎，在不增加實體的需求下，增加一個適配器，在里面包容一個虎對象，實現(xiàn)飛的接口。）

如何解決：繼承或依賴（推薦）。

關(guān)鍵代碼：適配器繼承或依賴已有的對象，實現(xiàn)想要的目標(biāo)接口。

應(yīng)用實例： 1、美國電器 110V，中國 220V，就要有一個適配器將 110V 轉(zhuǎn)化為 220V。 2、JAVA JDK 1.1 提供了 Enumeration 接口，而在 1.2 中提供了 Iterator 接口，想要使用 1.2 的 JDK，則要將以前系統(tǒng)的 Enumeration 接口轉(zhuǎn)化為 Iterator 接口，這時就需要適配器模式。 3、在 LINUX 上運行 WINDOWS 程序。 4、JAVA 中的 jdbc。

優(yōu)點： 1、可以讓任何兩個沒有關(guān)聯(lián)的類一起運行。 2、提高了類的復(fù)用。 3、增加了類的透明度。 4、靈活性好。

缺點： 1、過多地使用適配器，會讓系統(tǒng)非常零亂，不易整體進行把握。比如，明明看到調(diào)用的是 A 接口，其實內(nèi)部被適配成了 B 接口的實現(xiàn)，一個系統(tǒng)如果太多出現(xiàn)這種情況，無異于一場災(zāi)難。因此如果不是很有必要，可以不使用適配器，而是直接對系統(tǒng)進行重構(gòu)。 2.由于 JAVA 至多繼承一個類，所以至多只能適配一個適配者類，而且目標(biāo)類必須是抽象類。

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

　　Spring AOP 模塊對 BeforeAdvice、AfterAdvice、ThrowsAdvice 三種通知類型的支持實際上是借助適配器模式來實現(xiàn)的，這樣的好處是使得框架允許用戶向框架中加入自己想要支持的任何一種通知類型，上述三種通知類型是 Spring AOP 模塊定義的，它們是 AOP 聯(lián)盟定義的 Advice 的子類型。

　　在實際開發(fā)環(huán)境中，一般都會有登陸的功能，但是由于業(yè)務(wù)的拓展升級，登陸的方式也會有新的改變，可以有QQ登陸，微信登陸，手機號碼登陸等等，那么怎么在不影響原先的業(yè)務(wù)的情況下去拓展新的業(yè)務(wù)呢，那么這里就可以用適配器模式來拓展。

　　先定義一個service模擬線上已定的穩(wěn)定到不可變的登錄注冊業(yè)務(wù)接口及實現(xiàn)：

?

public interface ISigninService {//注冊方法public ResultMsg regist(String username,String password);// 登錄的方法public ResultMsg login(String username,String password); }public class SiginService implements ISigninService {/*** 注冊方法* @param username* @param password* @return*/public ResultMsg regist(String username, String password){return new ResultMsg("200","注冊成功",new Member());}/*** 登錄的方法* @param username* @param password* @return*/public ResultMsg login(String username,String password){return null;}}

?

　　其實涉及的 Menber 人員實體類及 ResultMsg 返回信息如下：

public class Member {private String username;private String password;// 唯一編號private String mid;// 具體信息private String info;//為節(jié)省篇幅，這里刪除了set跟get方法 }public class ResultMsg {//返回編碼private String code;// 返回信息private String msg;//返回數(shù)據(jù)private Object data;public ResultMsg(String code, String msg, Object data) {this.code = code;this.msg = msg;this.data = data;}//為節(jié)省篇幅，這里刪除了set跟get方法 }

　　現(xiàn)在業(yè)務(wù)拓展了，包括 QQ登陸，微信登陸，手機號碼登陸，怎么來做適配呢，當(dāng)然是繼承咯，看代碼：

public class SiginForThirdService extends SiginService {public ResultMsg loginForQQ(String openId){//1、openId是全局唯一，我們可以把它當(dāng)做是一個用戶名(加長)//2、密碼默認為是一個常量QQ_EMPTY//3、注冊（在原有系統(tǒng)里面創(chuàng)建一個用戶）//4、調(diào)用原來的登錄方法return loginForRegist(openId,null);}public ResultMsg loginForWechat(String openId){return null;}public ResultMsg loginForTelphone(String telphone,String code){return null;}// 這里封裝了原來的注冊跟登陸，想要用一個陌生的QQ來登陸，首先當(dāng)然是注冊// 注冊完調(diào)用一下登陸不久OK了嗎public ResultMsg loginForRegist(String username,String password){super.regist(username,null);return super.login(username,null);} }

　　這樣就完美的做到了業(yè)務(wù)的兼容。

轉(zhuǎn)載于:https://www.cnblogs.com/wuzhenzhao/p/10304939.html

總結(jié)

以上是生活随笔為你收集整理的设计模式之委派模式及适配器模式的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。