談談適配器模式

本文首發於個人我的博客，談談適配器模式 ，歡迎訪問！

適配器模式 (Adapter Pattern)：將一個接口轉換成客戶但願的另外一個接口，使接口不兼容的那些類能夠一塊兒工做，其別名爲包裝器 (Wrapper)。適配器模式既能夠做爲類結構型模式，也能夠做爲對象結構型模式。

設計模式的目的自己應該是使得軟件設計更具合理性，鬆耦合，易於擴展。咱們在學習的過程當中，不管是書上仍是博客上，通常都會描述模式的定義、UML 圖以及基本的實現方式。可是在我看來，在模式的實現和運用上彷佛並不須要徹底按照模式自己的結構來。

在 SpringMVC 中適配器模式主要用於執行目標 Controller 中的請求處理方法。

看了一些資料，在這裏感受使用 Adapter 的目的，無非是減小 if 的使用，而且減小大量的請求處理代碼和 DispatcherServlet 以前的耦合。由於不一樣的 Handler 有不一樣名稱的請求處理方法，若是不使用統一接口的 Adapter，勢必會添加一些硬編碼的類型判斷（Controller 和 Servlet 都是 Handler 的一種）。所以封裝一系列的 Adapter 與各個類型的 Handler 對應，在 DispatcherServlet 中就能夠直接經過 Handler 尋找合適的 Adapter。固然，Adapter 列表會在 Bean 初始化的過程當中預先加載好，因此本質上仍是遍歷匹配類型，可是在寫法和設計上和直接使用一組 I if 語句判斷有必定的區別。

在 JPA 中也是如此， JpaVendorAdapter 就是一個適配器，不一樣的 JPA 提供者須要去實現不一樣的 Adapter。實際上就是一個標準化的過程，這兩個例子所表現的都是一致的。雖然有不少的處理者，可是都有統一的方法接入。例如，HandlerAdapter 的 handle() 方法。最典型的插座的例子也是，不管輸入的電壓是 220v 仍是 110v，但我最終須要的就是 5v，這個就須要適配器來進行轉換。

設計模式就比如張三丰手裏的太極劍，不拘泥於招式，用意不用力，在往後開發過程當中還需慢慢體會。

Reference

• 淺談適配器設計模式
• 設計模式 | 適配器模式及典型應用
• SpringMVC 從 request 到 controller 過程詳解