一些設計上的基本常識

好文轉載留存，轉至http://javatar.iteye.com/blog/706098

1. API與SPI分離 

框架或組件通常有兩類客戶，一個是使用者，一個是擴展者， 
API(Application Programming Interface)是給使用者用的， 
而SPI(Service Provide Interface)是給擴展者用的， 
在設計時，儘量把它們隔離開，而不要混在一起， 
也就是說，使用者是看不到擴展者寫的實現的， 
比如：一個Web框架，它有一個API介面叫Action， 
裡面有個execute()方法，是給使用者用來寫業務邏輯的， 
然後，Web框架有一個SPI介面給擴展者控制輸出方式， 
比如用velocity模板輸出還是用json輸出等， 
如果這個Web框架使用一個都繼承Action的VelocityAction和一個JsonAction做為擴展方式， 
要用velocity模板輸出的就繼承VelocityAction，要用json輸出的就繼承JsonAction， 
這就是API和SPI沒有分離的反面例子，SPI介面混在了API介面中， 
合理的方式是，有一個單獨的Renderer介面，有VelocityRenderer和JsonRenderer實現， 
Web框架將Action的輸出轉交給Renderer介面做渲染輸出。 


 


 

2. 服務域/實體域/會話域分離 

任何框架或組件，總會有核心領域模型，比如： 
Spring的Bean，Struts的Action，Dubbo的Service，Napoli的Queue等等 
這個核心領域模型及其組成部分稱為實體域，它代表著我們要操作的目標本身， 
實體域通常是線程安全的，不管是通過不變類，同步狀態，或複製的方式， 
服務域也就是行為域，它是組件的功能集，同時也負責實體域和會話域的生命周期管理， 
比如Spring的ApplicationContext，Dubbo的ServiceManager等， 
服務域的對象通常會比較重，而且是線程安全的，並以單一實例服務於所有調用， 
什麼是會話？就是一次交互過程， 
會話中重要的概念是上下文，什麼是上下文？ 
比如我們說：“老地方見”，這裡的“老地方”就是上下文信息， 
為什麼說“老地方”對方會知道，因為我們前面定義了“老地方”的具體內容， 
所以說，上下文通常持有交互過程中的狀態變數等， 
會話對象通常較輕，每次請求都重新創建實例，請求結束後銷毀。 
簡而言之： 
把元信息交由實體域持有， 
把一次請求中的臨時狀態由會話域持有， 
由服務域貫穿整個過程。 

 

 

3. 在重要的過程上設置攔截介面 

如果你要寫個遠程調用框架，那遠程調用的過程應該有一個統一的攔截介面， 
如果你要寫一個ORM框架，那至少SQL的執行過程，Mapping過程要有攔截介面， 
如果你要寫一個Web框架，那請求的執行過程應該要有攔截介面， 
等等，沒有哪個公用的框架可以Cover住所有需求，允許外置行為，是框架的基本擴展方式， 
這樣，如果有人想在遠程調用前，驗證下令牌，驗證下黑白名單，統計下日誌， 
如果有人想在SQL執行前加下分頁包裝，做下數據許可權控制，統計下SQL執行時間， 
如果有人想在請求執行前檢查下角色，包裝下輸入輸出流，統計下請求量， 
等等，就可以自行完成，而不用侵入框架內部， 
攔截介面，通常是把過程本身用一個對象封裝起來，傳給攔截器鏈， 
比如：遠程調用主過程為invoke()，那攔截器介面通常為invoke(Invocation)， 
Invocation對象封裝了本來要執行過程的上下文，並且Invocation里有一個invoke()方法， 
由攔截器決定什麼時候執行，同時，Invocation也代表攔截器行為本身， 
這樣上一攔截器的Invocation其實是包裝的下一攔截器的過程， 
直到最後一個攔截器的Invocation是包裝的最終的invoke()過程， 
同理，SQL主過程為execute()，那攔截器介面通常為execute(Execution)，原理一樣， 
當然，實現方式可以任意，上面只是舉例。 

 

4. 重要的狀態的變更發送事件並留出監聽介面 

這裡先要講一個事件和上面攔截器的區別，攔截器是干預過程的，它是過程的一部分，是基於過程行為的， 
而事件是基於狀態數據的，任何行為改變的相同狀態，對事件應該是一致的， 
事件通常是事後通知，是一個Callback介面，方法名通常是過去式的，比如onChanged()， 
比如遠程調用框架，當網路斷開或連上應該發出一個事件，當出現錯誤也可以考慮發出一個事件， 
這樣外圍應用就有可能觀察到框架內部的變化，做相應適應。 

 

5. 擴展介面職責儘可能單一，具有可組合性 

比如，遠程調用框架它的協議是可以替換的， 
如果只提供一個總的擴展介面，當然可以做到切換協議， 
但協議支持是可以細分為底層通訊，序列化，動態代理方式等等， 
如果將介面拆細，正交分解，會更便於擴展者復用已有邏輯，而只是替換某部分實現策略， 
當然這個分解的粒度需要把握好。 

6. 微核插件式，平等對待第三方 

大凡發展的比較好的框架，都遵守微核的理念， 
Eclipse的微核是OSGi， Spring的微核是BeanFactory，Maven的微核是Plexus， 
通常核心是不應該帶有功能性的，而是一個生命周期和集成容器， 
這樣各功能可以通過相同的方式交互及擴展，並且任何功能都可以被替換， 
如果做不到微核，至少要平等對待第三方， 
即原作者能實現的功能，擴展者應該可以通過擴展的方式全部做到， 
原作者要把自己也當作擴展者，這樣才能保證框架的可持續性及由內向外的穩定性。 

7. 不要控制外部對象的生命周期 

比如上面說的Action使用介面和Renderer擴展介面， 
框架如果讓使用者或擴展者把Action或Renderer實現類的類名或類元信息報上來， 
然後在內部通過反射newInstance()創建一個實例， 
這樣框架就控制了Action或Renderer實現類的生命周期， 
Action或Renderer的生老病死，框架都自己做了，外部擴展或集成都無能為力， 
好的辦法是讓使用者或擴展者把Action或Renderer實現類的實例報上來， 
框架只是使用這些實例，這些對象是怎麼創建的，怎麼銷毀的，都和框架無關， 
框架最多提供工具類輔助管理，而不是絕對控制。 

8. 可配置一定可編程，並保持友好的CoC約定 

因為使用環境的不確定因素很多，框架總會有一些配置， 
一般都會到classpath直掃某個指定名稱的配置，或者啟動時允許指定配置路徑， 
做為一個通用框架，應該做到凡是能配置文件做的一定要能通過編程方式進行， 
否則當使用者需要將你的框架與另一個框架集成時就會帶來很多不必要的麻煩， 
另外，儘可能做一個標準約定，如果用戶按某種約定做事時，就不需要該配置項。 
比如：配置模板位置，你可以約定，如果放在templates目錄下就不用配了， 
如果你想換個目錄，就配置下。 

9. 區分命令與查詢，明確前置條件與後置條件 

這個是契約式設計的一部分，儘量遵守有返回值的方法是查詢方法，void返回的方法是命令， 
查詢方法通常是冪等性的，無副作用的，也就是不改變任何狀態，調n次結果都是一樣的， 
比如get某個屬性值，或查詢一條資料庫記錄， 
命令是指有副作用的，也就是會修改狀態，比如set某個值，或update某條資料庫記錄， 
如果你的方法即做了修改狀態的操作，又做了查詢返回，如果可能，將其拆成寫讀分離的兩個方法， 
比如：User deleteUser(id)，刪除用戶並返回被刪除的用戶，考慮改為getUser()和void的deleteUser()。 
另外，每個方法都儘量前置斷言傳入參數的合法性，後置斷言返回結果的合法性，並文檔化。 

10. 增量式擴展，而不要擴充原始核心概念 
參見：http://javatar.iteye.com/blog/690845