摘要: 經常地，你必須遍歷一個對象集合并基于一些條件（criteria）來過濾它們。JDK提供了有用的機制來排序集合，即Comparator接口。然而，JDK缺少過濾集合的機制。

這篇文章描述了一個僅由一個類和一個接口組成的簡單機制，它允許你快速和靈活地過濾集合。當搜索一個集合時，該機制提供了與SQL中的select語句相同的功能。它的隱含的概念是，在遍歷集合和過濾集合中的對象時，達到職責的分離。
這里提出的方法有下面的優點：
1、一個核心的過濾器組件的復用產生更清晰的代碼。
2、通用過濾組件的復用產生更免于錯誤的代碼。
3、從過濾邏輯中分離出迭代邏輯使你任意地增加和刪除過濾器而不影響到其他代碼。
4、對于大集合和多個criteria能夠獲得性能提高。  閱讀全文

     摘要: 對于沒有使用過Calendar的程序員來說，再次處理日期時不妨使用Calendar而不僅僅是Date和SimpleDateFormat等類。這篇文章根據幾個使用日期的場景來說明如何使用Calendar等類。
在數據庫編程時，我們通常將java日期字段選作Date型的（一般是java.sql.Date，繼承于java.util.Date，使用方法是類似的），當然也可以存儲為字符串甚至是long型的time，但我們這里只討論date型的。如果存儲的時間是系統當前時間，我們可以使用Date d = new Date();就得到想要的時間；以前我編程時也指定存儲日期的格式，但現在想來不是很有必要，完全可以在讀出數據時指定格式。另一種可選的方法是使用 Calendar類，方法如下：  閱讀全文

     摘要: 最近在看一個程序，該程序的圖形界面采用SWT編寫。想要將程序運行起來首先需要做的就是將swt（jface）包放到類路徑上，swt包可以從http://www.eclipse.org/swt下載（其中除了swt包還有和操作系統相關的文件），和swt開發相關的插件為VE。一切就緒，運行程序發現了“Exception in thread "main" java.lang.UnsatisfiedLinkError: no swt-pi-gtk-3232 in java.library.path ”的錯誤（我的操作系統為Ubuntu7.04）。解決方案有多種，這里只介紹我使用的一種方法。  閱讀全文

     摘要: 哈夫曼樹又稱最優二叉樹，是一種帶權路徑長度最短的二叉樹。所謂樹的帶權路徑長度，就是樹中所有的葉結點的權值乘上其到根結點的路徑長度（若根結點為0層，葉結點到根結點的路徑長度為葉結點的層數）。樹的帶權路徑長度記為WPL=(W1*L1+W2*L2+W3*L3+...+ Wn*Ln)，N個權值Wi(i=1,2,...n)構成一棵有N個葉結點的二叉樹，相應的葉結點的路徑長度為Li(i=1,2,...n)。可以證明哈夫曼樹的WPL是最小的。
構造哈夫曼樹的算法如下：
1）對給定的n個權值{W1,W2,W3,...,Wi,...,Wn}構成n棵二叉樹的初始集合F={T1,T2,T3,...,Ti,..., Tn}，其中每棵二叉樹Ti中只有一個權值為Wi的根結點，它的左右子樹均為空。
2）在F中選取兩棵根結點權值最小的樹作為新構造的二叉樹的左右子樹，新二叉樹的根結點的權值為其左右子樹的根結點的權值之和。
3）從F中刪除這兩棵樹，并把這棵新的二叉樹同樣以升序排列加入到集合F中。
4）重  閱讀全文

     摘要: 設有主串s和子串t，子串t定位是指在主串s中找到一個與子串t相等的子串。通常把主串s稱為目標串，把子串t稱為模式串，因此定位也稱作模式匹配。模式匹配成功是指在目標串s中找到一個模式串t。

傳統的字符串模式匹配算法（也就是BF算法）就是對于主串和模式串雙雙自左向右，一個一個字符比較，如果不匹配，主串和模式串的位置指針都要回溯。這樣的算法時間復雜度為O（n＊m），其中n和m分別為串s和串t的長度。

KMP算法是由Knuth，Morris和Pratt等人共同提出的，所以成為Knuth－Morris－Pratt算法，簡稱KMP算法。KMP算法是字符串模式匹配中的經典算法。和BF算法相比，KMP算法的不同點是匹配過程中，主串的位置指針不會回溯，這樣的結果使得算法時間復雜度只為O（n＋m）。下面說說KMP算法的原理。  閱讀全文

     摘要: 做java企業級開發時，我們通常采用三層架構。特別地，如果我們要做的系統的業務邏輯不是很復雜時，我們要處理的不過是CRUD操作，這時我們可能將dao層與service層合并為一層，盡管很多人會這樣做，但我仍傾向于將兩層分開；因為service與dao不是一一對應的，從復用及邏輯清晰的角度考慮，應該將它們分開。在三層架構下，對于web層，service層，dao層我們都該怎么測試？這里我將介紹基于Spring，Hibernate和DbUnit的情況下我的測試方法。由于使用了Spring，事務管理就不在dao，因此要單獨地測試dao可能要麻煩一些；另一方面，dao中的操作大多是簡單的，也不是很值得測試。在使用了Hibernate和Spring的情況下，我們要測試的除了HQL，還有其配置文件，我覺得對數據持久化的測試最好定在service上。如果service業務邏輯復雜的話，與數據持久化無關的業務邏輯（應該寫在領域對象中）可以單獨測試，在保證與數據持久化無關的業務邏輯的正確性下，帶上dao操作做集成（單元）測試。  閱讀全文

     摘要: 在做Java企業程序的時候，不可避免地要和外部資源打交道，比如數據庫，Http請求等。對于這些外部資源的處理，我們可采取的操作或者是直接處理或者是模擬處理。當我們使用Webwork，Spring，Hibernate等框架時，我們要測試的并不僅僅是Java代碼，我們還要測試依賴于這些框架的配置文件等等。因此，對于數據持久化的測試，Mock方法是行不通的，我們需要真實地測試數據庫操作。對于持久化測試來說，重要的是創造出已知的“干凈的”的準備數據。如果我們在測試一個持久化方法前不能確定數據庫到底存著什么數據，我們只能通過反復地查看數據庫數據來驗證測試方法的正確性了（這就是我和大多數人以前使用的最“直接”的方法）。現在就讓我們使用DbUnit，來更好的更自動化的測試持久化操作吧！

先介紹一下DbUnit。DbUnit是一個 JUnit擴展，適用于數據驅動的程序。使用DbUnit，可以在測試運行期間將數據庫的數據處于已知狀態，這樣在測試時可以方便地寫出測試斷言，也能自動地完成對數據持久化方法的測試。在使用上，DbUnit也很簡單， 它提供了大量的  閱讀全文

     摘要: 很早就知道Jetty，但直到最近才使用它作為Web服務器。Jetty是一個開放源碼的HTTP服務器和Java serverlet容器，是完全使用Java語言實現的。作為嵌入的Web服務器，Jetty被廣泛應用，比如DWR，JBoss，Geronimo，Tapestry中都使用了Jetty。相比于其他Web服務器，Jetty最大的有點就是小巧且啟動速度快。當前的Jetty最新版本為6，相比以前的版本“重”了不少，“重”的原因自然是功能的增強。我使用myeclipse插件開發Web程序，Web服務器從Tomcat轉換成Jetty只需改變一下程序部署的位置而已。  閱讀全文