2. 程式人生 > >責任鏈模式在tomcat的應用

責任鏈模式在tomcat的應用

阿新 • • 發佈：2018-12-15

一、責任鏈模式責任鏈模式是一種物件的行為模式。在責任鏈模式裡，很多物件由每一個物件對其下家的引用而連線起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個物件決定處理此請求。發出這個請求的客戶端並不知道鏈上的哪一個物件最終處理這個請求，這使得系統可以在不影響客戶端的情況下動態地重新組織和分配責任。 　責任鏈模式涉及到的角色如下所示：

　　●　　抽象處理者(Handler)角色：定義出一個處理請求的介面。如果需要，介面可以定義 出一個方法以設定和返回對下家的引用。這個角色通常由一個Java抽象類或者Java介面實現。上圖中Handler類的聚合關係給出了具體子類對下家的引用，抽象方法handleRequest()規範了子類處理請求的操作。

　　●　　具體處理者(ConcreteHandler)角色：具體處理者接到請求後，可以選擇將請求處理掉，或者將請求傳給下家。由於具體處理者持有對下家的引用，因此，如果需要，具體處理者可以訪問下家。

原始碼

　　抽象處理者角色

  1. public abstract class Handler {
  2.     /**
  3.      * 持有後繼的責任物件
  4.      */
  5.     protected Handler successor;
  6.     /**
  7.      * 示意處理請求的方法，雖然這個示意方法是沒有傳入引數的
  8.      * 但實際是可以傳入引數的，根據具體需要來選擇是否傳遞引數
  9.      */
  10.     public abstract void handleRequest();
  11.     /**
  12.      * 取值方法
  13.      */
  14.     public Handler getSuccessor() {
  15.         return successor;
  16.     }
  17.     /**
  18.      * 賦值方法，設定後繼的責任物件
  19.      */
  20.     public void setSuccessor(Handler successor) {
  21.         this.successor = successor;
  22.     }
  23. }

具體處理者角色

  1. public class ConcreteHandler extends Handler {
  2.     /**
  3.      * 處理方法，呼叫此方法處理請求
  4.      */
  5.     @Override
  6.     public void handleRequest() {
  7.         /**
  8.          * 判斷是否有後繼的責任物件
  9.          * 如果有，就轉發請求給後繼的責任物件
  10.          * 如果沒有，則處理請求
  11.          */
  12.         if(getSuccessor() != null)
  13.         { 
  14.             System.out.println("放過請求");
  15.             getSuccessor().handleRequest(); 
  16.         }else
  17.         { 
  18.             System.out.println("處理請求");
  19.         }
  20.     }
  21. }

客戶端類

  1. public class Client {
  2.     public static void main(String[] args) {
  3.         //組裝責任鏈
  4.         Handler handler1 = new ConcreteHandler();
  5.         Handler handler2 = new ConcreteHandler();
  6.         handler1.setSuccessor(handler2);
  7.         //提交請求
  8.         handler1.handleRequest();
  9.     }
  10. }

可以看出，客戶端建立了兩個處理者物件，並指定第一個處理者物件的下家是第二個處理者物件，而第二個處理者物件沒有下家。然後客戶端將請求傳遞給第一個處理者物件。

　　由於本示例的傳遞邏輯非常簡單：只要有下家，就傳給下家處理；如果沒有下家，就自行處理。因此，第一個處理者物件接到請求後，會將請求傳遞給第二個處理者物件。由於第二個處理者物件沒有下家，於是自行處理請求。活動時序圖如下所示。

使用場景

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

　　很多公司都是這樣的福利，就是專案組或者是部門可以向公司申請一些聚餐費用，用於組織專案組成員或者是部門成員進行聚餐活動。

　　申請聚餐費用的大致流程一般是：由申請人先填寫申請單，然後交給領導審批，如果申請批准下來，領導會通知申請人審批通過，然後申請人去財務領取費用，如果沒有批准下來，領導會通知申請人審批未通過，此事也就此作罷。

　　不同級別的領導，對於審批的額度是不一樣的，比如，專案經理只能審批500元以內的申請；部門經理能審批1000元以內的申請；而總經理可以稽核任意額度的申請。

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

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

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

原始碼

　　抽象處理者角色類

  1. public abstract class Handler {
  2.     /**
  3.      * 持有下一個處理請求的物件
  4.      */
  5.     protected Handler successor = null;
  6.     /**
  7.      * 取值方法
  8.      */
  9.     public Handler getSuccessor() {
  10.         return successor;
  11.     }
  12.     /**
  13.      * 設定下一個處理請求的物件
  14.      */
  15.     public void setSuccessor(Handler successor) {
  16.         this.successor = successor;
  17.     }
  18.     /**
  19.      * 處理聚餐費用的申請
  20.      * @param user 申請人
  21.      * @param fee 申請的錢數
  22.      * @return 成功或失敗的具體通知
  23.      */
  24.     public abstract String handleFeeRequest(String user , double fee);
  25. }

具體處理者角色

  1. public class ProjectManager extends Handler {
  2.     @Override
  3.     public String handleFeeRequest(String user, double fee) {
  4.         String str = "";
  5.         //專案經理許可權比較小，只能在500以內
  6.         if(fee < 500)
  7.         {
  8.             //為了測試，簡單點，只同意張三的請求
  9.             if("張三".equals(user))
  10.             {
  11.                 str = "成功：專案經理同意【" + user + "】的聚餐費用，金額為" + fee + "元"; 
  12.             }else
  13.             {
  14.                 //其他人一律不同意
  15.                 str = "失敗：專案經理不同意【" + user + "】的聚餐費用，金額為" + fee + "元";
  16.             }
  17.         }else
  18.         {
  19.             //超過500，繼續傳遞給級別更高的人處理
  20.             if(getSuccessor() != null)
  21.             {
  22.                 return getSuccessor().handleFeeRequest(user, fee);
  23.             }
  24.         }
  25.         return str;
  26.     }
  27. }
  1. public class ProjectManager extends Handler {
  2.     @Override
  3.     public String handleFeeRequest(String user, double fee) {
  4.         String str = "";
  5.         //專案經理許可權比較小，只能在500以內
  6.         if(fee < 500)
  7.         {
  8.             //為了測試，簡單點，只同意張三的請求
  9.             if("張三".equals(user))
  10.             {
  11.                 str = "成功：專案經理同意【" + user + "】的聚餐費用，金額為" + fee + "元"; 
  12.             }else
  13.             {
  14.                 //其他人一律不同意
  15.                 str = "失敗：專案經理不同意【" + user + "】的聚餐費用，金額為" + fee + "元";
  16.             }
  17.         }else
  18.         {
  19.             //超過500，繼續傳遞給級別更高的人處理
  20.             if(getSuccessor() != null)
  21.             {
  22.                 return getSuccessor().handleFeeRequest(user, fee);
  23.             }
  24.         }
  25.         return str;
  26.     }
  27. }
  1. public class DeptManager extends Handler {
  2.     @Override
  3.     public String handleFeeRequest(String user, double fee) {
  4.         String str = "";
  5.         //部門經理的許可權只能在1000以內
  6.         if(fee < 1000)
  7.         {
  8.             //為了測試，簡單點，只同意張三的請求
  9.             if("張三".equals(user))
  10.             {
  11.                 str = "成功：部門經理同意【" + user + "】的聚餐費用，金額為" + fee + "元"; 
  12.             }else
  13.             {
  14.                 //其他人一律不同意
  15.                 str = "失敗：部門經理不同意【" + user + "】的聚餐費用，金額為" + fee + "元";
  16.             }
  17.         }else
  18.         {
  19.             //超過1000，繼續傳遞給級別更高的人處理
  20.             if(getSuccessor() != null)
  21.             {
  22.                 return getSuccessor().handleFeeRequest(user, fee);
  23.             }
  24.         }
  25.         return str;
  26.     }
  27. }
  1. public class GeneralManager extends Handler {
  2.     @Override
  3.     public String handleFeeRequest(String user, double fee) {
  4.         String str = "";
  5.         //總經理的許可權很大，只要請求到了這裡，他都可以處理
  6.         if(fee >= 1000)
  7.         {
  8.             //為了測試，簡單點，只同意張三的請求
  9.             if("張三".equals(user))
  10.             {
  11.                 str = "成功：總經理同意【" + user + "】的聚餐費用，金額為" + fee + "元"; 
  12.             }else
  13.             {
  14.                 //其他人一律不同意
  15.                 str = "失敗：總經理不同意【" + user + "】的聚餐費用，金額為" + fee + "元";
  16.             }
  17.         }else
  18.         {
  19.             //如果還有後繼的處理物件，繼續傳遞
  20.             if(getSuccessor() != null)
  21.             {
  22.                 return getSuccessor().handleFeeRequest(user, fee);
  23.             }
  24.         }
  25.         return str;
  26.     }
  27. }

客戶端類  

  1. public class Client {
  2.     public static void main(String[] args) {
  3.         //先要組裝責任鏈
  4.         Handler h1 = new GeneralManager();
  5.         Handler h2 = new DeptManager();
  6.         Handler h3 = new ProjectManager();
  7.         h3.setSuccessor(h2);
  8.         h2.setSuccessor(h1);
  9.         //開始測試
  10.         String test1 = h3.handleFeeRequest("張三", 300);
  11.         System.out.println("test1 = " + test1);
  12.         String test2 = h3.handleFeeRequest("李四", 300);
  13.         System.out.println("test2 = " + test2);
  14.         System.out.println("---------------------------------------");
  15.         String test3 = h3.handleFeeRequest("張三", 700);
  16.         System.out.println("test3 = " + test3);
  17.         String test4 = h3.handleFeeRequest("李四", 700);
  18.         System.out.println("test4 = " + test4);
  19.         System.out.println("---------------------------------------");
  20.         String test5 = h3.handleFeeRequest("張三", 1500);
  21.         System.out.println("test5 = " + test5);
  22.         String test6 = h3.handleFeeRequest("李四", 1500);
  23.         System.out.println("test6 = " + test6);
  24.     }
  25. }

純的與不純的責任鏈模式

　　一個純的責任鏈模式要求一個具體的處理者物件只能在兩個行為中選擇一個：一是承擔責任，而是把責任推給下家。不允許出現某一個具體處理者物件在承擔了一部分責任後又 把責任向下傳的情況。

　　在一個純的責任鏈模式裡面，一個請求必須被某一個處理者物件所接收；在一個不純的責任鏈模式裡面，一個請求可以最終不被任何接收端物件所接收。

　　純的責任鏈模式的實際例子很難找到，一般看到的例子均是不純的責任鏈模式的實現。有些人認為不純的責任鏈根本不是責任鏈模式，這也許是有道理的。但是在實際的系統裡，純的責任鏈很難找到。如果堅持責任鏈不純便不是責任鏈模式，那麼責任鏈模式便不會有太大意義了。

責任鏈模式在Tomcat中的應用

　過對Tomcat8.5.5版本的原始碼進行學習，發現Tomcat中有2個地方用到了責任鏈模式，一個是管道中的閥門，另一個是過濾器鏈中的過濾器。下面我們分別來看一下這兩個責任鏈模式具體是如何使用的。 Filter介面如下所示：

public interface Filter { public void doFilter(ServletRequest request, ServletResponse response,
            FilterChain chain);
}

Filter介面是所有具體過濾器必須實現的介面，該介面有一個核心的方法doFilter，方法對Request和Response進行處理，注意第三個引數型別為FilterChain，傳入該引數的目的是為了責任能夠傳遞到下一個過濾器。  具體Filter如下所示： public class MyFilter implements Filter{ @Override public void doFilter(ServletRequest request, ServletResponse response,

 FilterChain chain) { //處理request和response //... chain.doFilter(request,response);
    }
}

首先根據需求對request和response進行處理，最後需要呼叫過濾器鏈中的doFilter方法以便責任能夠傳遞到下一個過濾器。chain.doFilter(request,response)，注意這個doFilter是FilterChain中的doFilter與Filter中的doFilter沒有任何關係，名字雖然相同，但是引數是不一樣的。FilterChain中的doFilter只有Request和Response兩個引數，其實更好的命名方式應該是chain.doNextFilter(resquest,response)

那麼，FilterChain是什麼樣的呢？我們上面已經看到了FilterChain的用法，也知道了FilterChain在呼叫doFilter(request,response)的時候需要有能力將任務傳遞到下一個Filter,因此我們可以推斷，FilterChain中需要儲存所有的Filter。在Tomcat的實現中，正是在FilterChain中用一個數組儲存了所有的Filter,這不禁讓我想起了java.util.ArrayList的實現。  在Tomcat中FilterChain也是一個介面，如下所示：

public interface FilterChain { public void doFilter(ServletRequest request, ServletResponse response);
}

而ApplicationFilterChain實現了FilterChain,其核心程式碼如下所示：  

  1. public void doFilter(ServletRequest request, ServletResponse response)
  2.         throws IOException, ServletException {
  3.         if( Globals.IS_SECURITY_ENABLED ) {
  4.             final ServletRequest req = request;
  5.             final ServletResponse res = response;
  6.             try {
  7.                 java.security.AccessController.doPrivileged(
  8.                     new java.security.PrivilegedExceptionAction<Void>() {
  9.                         @Override
  10.                         public Void run() 
  11.                             throws ServletException, IOException {
  12.                             internalDoFilter(req,res);
  13.                             return null;
  14.                         }
  15.                     }
  16.                 );
  17.             } catch( PrivilegedActionException pe) {
  18.                 Exception e = pe.getException();
  19.                 if (e instanceof ServletException)
  20.                     throw (ServletException) e;
  21.                 else if (e instanceof IOException)
  22.                     throw (IOException) e;
  23.                 else if (e instanceof RuntimeException)
  24.                     throw (RuntimeException) e;
  25.                 else
  26.                     throw new ServletException(e.getMessage(), e);
  27.             }
  28.         } else {
  29.             internalDoFilter(request,response);
  30.         }
  31.     }
  32.     private void internalDoFilter(ServletRequest request, 
  33.                                   ServletResponse response)
  34.         throws IOException, ServletException {
  35.         // Call the next filter if there is one
  36.         if (pos < n) {
  37. //在鏈執行過程中，當pos
  38.             ApplicationFilterConfig filterConfig = filters[pos++];
  39.             Filter filter = null;
  40.             try {
  41.                 filter = filterConfig.getFilter();
  42.                 support.fireInstanceEvent(InstanceEvent.BEFORE_FILTER_EVENT,
  43.                                           filter, request, response);
  44.                 if (request.isAsyncSupported() && "false".equalsIgnoreCase(
  45.                         filterConfig.getFilterDef().getAsyncSupported())) {
  46.                     request.setAttribute(Globals.ASYNC_SUPPORTED_ATTR,
  47.                             Boolean.FALSE);
  48.                 }
  49.                 if( Globals.IS_SECURITY_ENABLED ) {
  50.                     final ServletRequest req = request;
  51.                     final ServletResponse res = response;
  52.                     Principal principal = 
  53.                         ((HttpServletRequest) req).getUserPrincipal();
  54.                     Object[] args = new Object[]{req, res, this};
  55.                     SecurityUtil.doAsPrivilege
  56.                         ("doFilter", filter, classType, args, principal);
  57.                 } else { 
  58.                     filter.doFilter(request, response, this);
  59.                 }
  60.                 support.fireInstanceEvent(InstanceEvent.AFTER_FILTER_EVENT,
  61.                                           filter, request, response);
  62.             } catch (IOException e) {
  63.                 if (filter != null)
  64.                     support.fireInstanceEvent(InstanceEvent.AFTER_FILTER_EVENT,
  65.                                               filter, request, response, e);
  66.                 throw e;
  67.             } catch (ServletException e) {
  68.                 if (filter != null)
  69.                     support.fireInstanceEvent(InstanceEvent.AFTER_FILTER_EVENT,
  70.                                               filter, request, response, e);
  71.                 throw e;
  72.             } catch (RuntimeException e) {
  73.                 if (filter != null)
  74.                     support.fireInstanceEvent(InstanceEvent.AFTER_FILTER_EVENT,
  75.                                               filter, request, response, e);
  76.                 throw e;
  77.             } catch (Throwable e) {
  78.                 e = ExceptionUtils.unwrapInvocationTargetException(e);
  79.                 ExceptionUtils.handleThrowable(e);
  80.                 if (filter != null)
  81.                     support.fireInstanceEvent(InstanceEvent.AFTER_FILTER_EVENT,
  82.                                               filter, request, response, e);
  83.                 throw new ServletException
  84.                   (sm.getString("filterChain.filter"), e);
  85.             }
  86.             return;
  87.         }
  88.         // We fell off the end of the chain -- call the servlet instance
  89.         try {
  90.             if (ApplicationDispatcher.WRAP_SAME_OBJECT) {
  91.                 lastServicedRequest.set(request);
  92.                 lastServicedResponse.set(response);
  93.             }
  94.             support.fireInstanceEvent(InstanceEvent.BEFORE_SERVICE_EVENT,
  95.                                       servlet, request, response);
  96.             if (request.isAsyncSupported()
  97.                     && !support.getWrapper().isAsyncSupported()) {
  98.                 request.setAttribute(Globals.ASYNC_SUPPORTED_ATTR,
  99.                         Boolean.FALSE);
  100.             }
  101.             // Use potentially wrapped request from this point
  102.             if ((request instanceof HttpServletRequest) &&
  103.                 (response instanceof HttpServletResponse)) {
  104.                 if( Globals.IS_SECURITY_ENABLED ) {
  105.                     final ServletRequest req = request;
  106.                     final ServletResponse res = response;
  107.                     Principal principal = 
  108.                         ((HttpServletRequest) req).getUserPrincipal();
  109.                     Object[] args = new Object[]{req, res};
  110.                     SecurityUtil.doAsPrivilege("service",
  111.                                                servlet,
  112.                                                classTypeUsedInService, 
  113.                                                args,
  114.                                                principal); 
  115.                 } else { 
  116.                     servlet.service(request, response);
  117.                 }
  118.             } else {
  119.                 servlet.service(request, response);
  120.             }
  121.             support.fireInstanceEvent(InstanceEvent.AFTER_SERVICE_EVENT,
  122.                                       servlet, request, response);
  123.         } catch (IOException e) {
  124.             support.fireInstanceEvent(InstanceEvent.AFTER_SERVICE_EVENT,
  125.                                       servlet, request, response, e);
  126.             throw e;
  127.         } catch (ServletException e) {
  128.             support.fireInstanceEvent(InstanceEvent.AFTER_SERVICE_EVENT,
  129.                                       servlet, request, response, e);
  130.             throw e;
  131.         } catch (RuntimeException e) {
  132.             support.fireInstanceEvent(InstanceEvent.AFTER_SERVICE_EVENT,
  133.                                       servlet, request, response, e);
  134.             throw e;
  135.         } catch (Throwable e) {
  136.             ExceptionUtils.handleThrowable(e);
  137.             support.fireInstanceEvent(InstanceEvent.AFTER_SERVICE_EVENT,
  138.                                       servlet, request, response, e);
  139.             throw new ServletException
  140.               (sm.getString("filterChain.servlet"), e);
  141.         } finally {
  142.             if (ApplicationDispatcher.WRAP_SAME_OBJECT) {
  143.                 lastServicedRequest.set(null);
  144.                 lastServicedResponse.set(null);
  145.             }
  146.         }
  147.     }

可以看出在FilterChain的實現中確實是用陣列來儲存所有的過濾器，但是並不是直接儲存的Filter型別，而是儲存的FilterConfig型別，可以把FilterConfig當做Filter的包裝類，我們可以通過filterConfig.getFilter()拿到Filter例項。在internalDoFilter方法中我們看到了FilterChain是如何實現責任的傳遞的，通過pos和n這兩個變數來判斷有沒有傳遞到過濾器鏈的最後面，如果沒有到最後，則取出當前過濾器並呼叫filter.doFilter的方法，在前面MyFilter的實現當中，它的doFilter方法在最後又呼叫了chain.doFilter(),從而保證了過濾器鏈能夠將責任傳遞到下一個過濾器中。pos和n這兩個變數的作用又讓我聯想到了ArrayList中的迭代器的實現。 客戶端程式碼如下：  

  1. public class Client{
  2.     public static void main(String[] args) {
  3.         Request request = new Request();
  4.         Response response = new Response();
  5.         Filter filter1 = new MyFilter1();
  6.         Filter filter2 = new MyFilter2();
  7.         Filter filter3 = new MyFilter3();
  8.         FilterChain chain = new ApplicationFilterChain();
  9.         ApplicationFilterConfig filterConfig1 = new ApplicationFilterConfig(filter1);
  10.         ApplicationFilterConfig filterConfig2 = new ApplicationFilterConfig(filter2);
  11.         ApplicationFilterConfig filterConfig3 = new ApplicationFilterConfig(filter3);
  12.         chain.addFilter(filterConfig1);
  13.         chain.addFilter(filterConfig2);
  14.         chain.addFilter(filterConfig3);
  15.         chain.doFilter(request, response);
  16.     }
  17. }

以下是Filter介面doFilter定義如下  public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)

過濾器鏈裡面的filter在呼叫dofilter完成後，會繼續呼叫chain.doFilter(request,response)方法，而這個chain其實就是applicationfilterchain,所以呼叫過程又回到了上面呼叫dofilter和呼叫internalDoFilter方法，這樣執行直到裡面的過濾器全部執行

當filte都呼叫完成後，它就會初始化相應的servlet

相關推薦

責任鏈模式的應用

一、責任鏈模式概念         鏈是一系列節點的集合，鏈的各節點可以靈活的拆分重組。當一個請求需要多個物件進行處理，將多個物件串成一個鏈路，從而避免了請求傳送者和接收者之間的耦合關係。請求者不知道是鏈路上的哪個節點做了處理。二、優缺點         優點： 1. 降低了

責任鏈模式的應用例項

    對於一般的程式設計師而言，在平時的coding當中並沒有刻意去應用什麼模式。但最近我的一個體會就是，當你發現已完成功能的實現程式碼，其侵入性非常之高；再從軟體產品整體的角度去俯瞰，該部分程式碼甚至已經完全不符合OCP、SRP等原則了，需求稍有變更，就需要有傷筋動骨

責任鏈模式在tomcat的應用

一、責任鏈模式責任鏈模式是一種物件的行為模式。在責任鏈模式裡，很多物件由每一個物件對其下家的引用而連線起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個物件決定處理此請求。發出這個請求的客戶端並不知道鏈上的哪一個物件最終處理這個請求，這使得系統可以在不影響客戶端的情況下動態

Java設計模式應用——責任鏈模式

調用 stat 事務 抽象類 pan 主動 需要 return 包含 生產一個產品，需要依次執行多個步驟，才能完成，那麽是使用責任鏈模式則是極好的。 在性能告警模塊開發過程中，創建一條告警規則需要執行閾值解析，中間表生成，流任務生成，規則入庫，告警事件入庫等諸多操作。如果把

設計模式 | 責任鏈模式及典型應用

本文的主要內容： 介紹責任鏈模式 請假流程示例 責任鏈模式總結 原始碼分析Tomcat Filter中的責任鏈模式 更多內容可訪問我的個人部落格：laijianfeng.org 關注【小旋鋒】微信公眾號，及時接收博文推送 **** 責任鏈模式 一個事

責任鏈模式在專案中的實際應用(Java)

1.責任鏈模式 首先簡單介紹一下責任鏈模式。 定義：使多個物件都有機會處理請求，從而避免了請求的傳送者和接受者之間的耦合關係。將這些物件連成一條鏈，並沿著這條鏈傳遞該請求，直到有物件處理它為止。將所有處理者形成一條鏈，在鏈中決定哪個物件能夠處理請求，並返回結果，不能處理則

責任鏈模式和工廠模式在處理被動響應訊息中的應用

        在公眾號建設中，傳送被動響應訊息是最核心的環節，使用者主動發給微信的訊息經微信伺服器處理後，統一變成xml格式的報文，微信公眾平臺後臺需要對這些報文進行分別處理，然後組織響應報文響應給使用者，同時針對某些特殊操作的行為需要修改資料庫的某些資訊。      

責任鏈模式在 iOS 中的應用

名稱 責任鏈模式 Chain of Responsibility Pattren 用途 解耦訊息的傳送者和接受者。 讓多個物件有機會處理某個請求（UI 響應鏈、Planck 中介軟體、流式

設計模式與應用：責任鏈模式

本文介紹責任鏈模式的基本結構、應用場景、以及現有一些成熟框架的應用 簡介 Chain of Responsibility(CoR)模式也叫職責鏈模式、責任鏈模式。是行為模式之一 責任鏈模式構造一系列分別擔當不通的職責的類的

關於責任鏈模式與模版模式的應用

模版模式是建立一個抽象類或介面，抽象類中有完成一個任務的步驟1，2，3，如果步驟1與3相同，只是步驟2的執行不同，那麼可以建立子類繼承抽象類或者不同子類介面實現介面，從而完成整個任務。例如：public interface A{     void yunSuan(Object

設計模式—責任鏈模式

[] .com repl ring replace servlet 就業 返回 array 責任鏈將處理請求在鏈條的節點上傳遞，每到一個節點可被處理或者也可不被處理。 典型的是在servlet中過濾器filter的的處理方式。當request請求或者response請求時，

設計模式之責任鏈模式

設計模式 責任鏈模式 chain of responsibility 1、責任鏈模式 chainOfResponsiblity : a、責任鏈模式屬於行為型模式，行為型模式關註系統中對象之間的相互交互，研究系統在運行時對象之間的相互通信和協作，進一步明確對象的職責，共有11中模式。 b

跟我學設計模式視頻教程——管擦者模式（下），責任鏈模式（上）

tar eight color font content 設計模式 name -m ack 課程視頻 觀察者模式（下） 責任鏈模式（上） 課程筆記 課程筆記 課程代碼 課程代碼 新課程火熱報名中 課程介紹

責任鏈模式（chain of responsbility）

src private ons wan resp ring bject send 都是 責任鏈模式定義如下： 　　avoid coupling the sender of a request to its receiver by giving more than one o

請求的鏈式處理——責任鏈模式

next return pop extend pri fin 職責 人員 spa 什麽是責任鏈模式 職責鏈能夠是一條直線、一個環或者一個樹形結構，最常見的職責鏈是直線型。即沿著一條單向的鏈來傳遞請求。鏈上的每個對象都是請求處理者。職責鏈模式能夠將請求的

java設計模式（五）責任鏈模式

args 測試 處理 next 設計 ted static rgs stat 　　很多對象有每個對象對其下家的引用而連接起來形成一條鏈，請求在這條鏈上傳遞，直到鏈上某個對象決定處理此請求，應用場景如單位審批流程等。 　　要點：1）抽象處理者角色：定義處理請求接口及設定下家引

java 設計模式 -- 責任鏈模式

ddc 結果 fun intercept lock -s xtend print blog 設計模式 – 責任鏈模式 介紹： 責任鏈模式是一種動態行為模式，有多個對象，每一個對象分別擁有其下家的引用。連起來形成一條鏈。待處理對象則傳到此鏈上

【設計模式】責任鏈模式

receive req evel 自己 缺點 結果 改革 == 引用 1、定義 1.1 標準定義 Avoid coupling the sender of a request to its receiver by giving more than one object a

責任鏈模式

響應 tom void req str 信息 bounds art .get 一、概述： 使多個對象都有機會處理請求，從而避免請求的發送者和接收者之間的耦合關系。將這些對象連成一條鏈，並沿著這條鏈傳遞該請求，直到有一個對象處理它為止。比如有異常鏈、tomcat的filter

設計模式(13)--Chain of Responsibility(責任鏈模式)--行為型

sse 之前 對象 接收 高級 組裝 的人 exe 必須 1.模式定義: 　　責任鏈模式是一種對象的行為模式。在責任鏈模式裏，很多對象由每一個對象對其下家的引用而連接起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個對象決定處理此請求。發出這個請求的客戶端並不知道鏈上的