框架設計的本質
原創宣告 ：本文系作者原創，謝絕個人、媒體、公眾號或網站 未經授 權 轉載，違者追究其法律責任。
框架設計的本質是一個非常大的話題，專門為此寫一本書都有可能，不過寫書遠遠超出筆者的能力。本文從一個很小的點切入，僅簡單介紹筆者理解的框架設計的本質，並基於此分析部分開源框架的內部實現。如果您有不一樣的觀點，歡迎留言探討。受限於筆者的能力範圍，本文介紹和分析的框架均使用 Java 語言實現，但這並不意味著本文介紹的框架設計的本質僅適用於 Java，事實上它適用於任何一門程式語言實現的軟體框架。
維基百科軟體框架詞條列出了軟體框架與軟體庫或應用之間關鍵的三點區別：
-
反轉控制 (Inversion of Control) - 框架控制應用的流程，而不是呼叫者。
-
擴充套件性 (extensibility) - 應用可以擴充套件框架的功能。
-
框架本身不可修改 (non-modifiable framework code) - 應用擴充套件框架的功能且無需修改框架自身的程式碼，即遵循 OCP 原則。
所以，軟體框架設計的本質是為軟體框架設計一套良好的擴充套件機制。在框架中，實現豐富的功能很重要，更重要的是框架有一套良好的擴充套件機制，基於這套擴充套件機制使用者不僅可以擴充套件框架的功能，還能替換框架已實現的功能。
觀察 Java 社群的開源框架，優秀的框架都有一套良好的擴充套件機制，這套機制可以使框架應對不斷變化的業務需求。比如：
-
Tapestry 5 開發了可擴充套件的 IOC 容器 。
-
Spring Web MVC 建立在 Spring IOC 之上。
-
Dubbo 實現了一套擴充套件機制 ExtensionLoader 。
下面以 Spring Web MVC 為例分析一下在 Spring IOC 之上如何實現它的擴充套件機制。
Spring Web MVC 的核心是 DispatcherServlet，DispatcherServlet 使用一些介面處理 HTTP 請求生成 HTTP 響應，比如 HandlerMapping 介面把 HTTP 請求
對映到一個處理器以及一些前置、後置攔截器，ViewResolver 介面把邏輯檢視解析為渲染 HTTP 響應的 View 物件。
DispatcherServlet 初始化時，首先使用工具方法 org.springframework.beans.factory.BeanFactoryUtils.beansOfTypeIncludingAncestors 從 Spring ApplicationContext 中獲取介面的實現，找不到則從配置檔案 DispatcherServlet.properties 獲取預設實現類並註冊到 ApplicationContext 中。如果應用需要使用自定義的渲染引擎渲染 HTTP 響應，實現 ViewResolver 介面並把實現類註冊到 Spring ApplicationContext 中就能擴充套件 ViewResolver，
替換或擴充套件 Spring Web MVC 的預設實現。
結合前面介紹的框架三要素簡單分析一下 Spring Web MVC 的擴充套件機制：
-
構建在 Spring IOC 之上；
-
實現 Spring Web MVC 定義的 介面 來擴充套件框架的功能；
-
在 Spring IOC 中註冊自定義實現的類就能使用擴充套件的功能，不需要修改框架的程式碼。
本文介紹了筆者理解的軟體框架設計的本質：設計一套良好的擴充套件機制，並分析了 Spring Web MVC 的擴充套件機制。那麼問題來了，設計框架時如何設計、實現一套滿足以上三個要素的輕量級通用可擴充套件機制呢？歡迎各位看官在留言中提供您的設計、實現方案。
參考：
-
軟體框架：https://en.wikipedia.org/wiki/Software_framework
-
IOC 容器：http://tapestry.apache.org/ioc.html
-
OCP 原則：https://en.wikipedia.org/wiki/Open/closed_principle
-
Tapestry 5：http://tapestry.apache.org/
-
Spring Web MVC：https://projects.spring.io/spring-framework/
-
Dubbo：http://dubbo.io/
