委派模式：

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

應用場景：不屬于 23 種設計模式之一，是面向對象設計模式中常用的一種模式。這種模式的原理為類 B和類 A 是兩個互相沒有任何關系的類，B 具有和 A 一模一樣的方法和屬性；并且調用 B 中的方法，屬性就是調用 A 中同名的方法和屬性。B 好像就是一個受 A 授權委托的中介。第三方的代碼不需要知道 A 的存在，也不需要和 A 發生直接的聯系，通過 B 就可以直接使用 A 的功能，這樣既能夠使用到 A 的各種功能，又能夠很好的將 A 保護起來了，一舉兩得。

意圖：

　　定義抽象接口的一個實現類, 他負責判斷和調用哪個實現類的實例。

優點: 對內隱藏實現, 易于擴展; 簡化調用;

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

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

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

　　先定義一個抽象類：

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

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

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

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

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

　　最后來個測試類，Boss 來發布任務了，這樣子項目經理會委派底下的人去干活，而自己干了一下調度的活。

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

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

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

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

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

適配器模式：

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

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

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

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

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

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

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

　　先定義一個service模擬線上已定的穩定到不可變的登錄注冊業務接口及實現：

?

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;//為節省篇幅，這里刪除了set跟get方法 }public class ResultMsg {//返回編碼private String code;// 返回信息private String msg;//返回數據private Object data;public ResultMsg(String code, String msg, Object data) {this.code = code;this.msg = msg;this.data = data;}//為節省篇幅，這里刪除了set跟get方法 }

　　現在業務拓展了，包括 QQ登陸，微信登陸，手機號碼登陸，怎么來做適配呢，當然是繼承咯，看代碼：

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

　　這樣就完美的做到了業務的兼容。

轉載于:https://www.cnblogs.com/wuzhenzhao/p/10304939.html

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。