程序中的各種類(Class),包(package)等首先體現的是架構設計中的一種概念分布. 一個良好的設計相當於是建立一個結構合理的概念框架, 隨著系統的不斷發展, 作為概念載體的類(Class)不斷吸收相關的實現, 從而使其外延不斷豐富起來, 而其內涵也愈加變得明晰. 系統中概念的分化, 最顯著的不是業務模塊的劃分, 而是技術層面與業務層面的分離. 因為技術手段與業務在很大程度上是相互獨立的, 因為 [無論]實現什麼樣的業務, 我們[都]將用到某種技術手段. 而當我們可以回答一個"無論..都" 的問題的時候, 它意味著某個概念可以容納眾多變化, 而它自然有資格成為某種獨立的部分.
作為技術層面概念聚集的例子, 我們可以看一下spring framework中的JdbcTemplate類, 這個類在spring的概念體系中對應於"Jdbc調用幫助類"這一概念, 它的目的是幫助我們盡量通過一次函數調用得到我們所要的結果, 但是我已經不止一次的看到很多人使用如下調用
List results = jdbcTemplate.query(...);
List ret = new ArrayList();
for(int i=0;i
ret.add(((Map)results.get(i)).get("someFIEld"));
}
這段代碼的目的是為了得到某一列的值, 而JdbcTemplate類沒有直接提供這一函數. 為了不等待spring的升級, 顯然我們需要建立一個JdbcTemplate的擴展類, 它直接提供一個queryScalarList函數, 而不是讓這種純粹技術性的循環語句散見在程序代碼的各個角落.
告別裸奔編程是我對同事的基本要求之一. 即使是考慮最細致的軟件組件, 它也難以保證能夠預想到所有的變化形式, 而在系統中集成一些第三方組件的時候, 一般總要加入一些特定的假設, 此時也需要一個技術隔離層. 例如在頁面開發中, 我們強制使用witrix平台定義的js.Ajax對象, 而不是prototype.js中原始提供的Ajax.Updater等對象. 在應用一段時間之後, JS.Ajax對象上聚集了一系列與AJax相關的調用指令.
