re: 消除實現繼承和面向接口編程 InPractice 2007-09-08 10:56
我就很反感一個接口一個實現的方式。當然這是以我的項目經驗為前提的（不排除目光偏狹的可能性）。
這種預留的擴展余地，即將來可以加入其他的實現。在我的項目中事實上成為了“過度工程”的例子。因為到現在為止還是一個接口一個實現。倒是每次讀代碼是多了一個間接級別，麻煩了很多，效率降低。有人可能爭辯說，代碼讀起來麻煩點沒有關系，設計上還是優美的。我不同意這種觀點，現實中的代碼讀的次數遠遠超過寫的次數，讀代碼效率降低的影響不是一個所謂的優美的（在我看是華而不實）設計可以彌補的。
在我看來，一個接口一個實現， 恰恰是當前流行的反模式。盡管可能在某些情況下有其合理性，但多數是對“面向接口編程”的濫用。
JDK中既有快速排序，也有merge－insertation 排序。
前者基本上用于 primitive 的排序。
后者基本上用于對象數數組的排序。
re: 防止任意形式的重復提交 InPractice 2006-05-09 07:12
其實還有比較難處理的情況:
return mapping.findForward(" 這種情況下就是重復提交，轉到相應的頁面 ");
在應用中,這個相應的頁面可能是動態的.
比如說首次提交是成功的,那么重復提交就應該也到成功頁面.
如果首次提交是失敗的,那么重復提交就應該也到失敗頁面.
但是在代碼中我們只知道是重復提交,卻不知道首次提交的結果.
所以無法決定應該轉到什么頁面.
當然, 如果技術能夠驅動需求, 比如發生重復提交時顯示指定的頁面.
問題可以解決.但是把技術上的問題暴露給用戶,終歸不是很友好.
re: [轉貼]有效編寫軟件的75條建議 InPractice 2006-04-15 21:22
寫得很好，瀏覽了一遍，和我的開發實踐和見解吻合。
re: SOA的三個方面（原創翻譯） InPractice 2006-04-08 19:32
能把IBM 的咨詢師在中遠演示 SOA 留下的 PPT 發給我一份嗎？
我的郵箱是ueddieu@yahoo.com.cn
先謝過了。
我覺得關鍵是不同的Validator都能得到調用。Decoraotr可以實現，用Chain Of Responsibility模式也可以實現。至于這兩者之間的取舍，需要根據更具體的需求才能確定。
re: 影響性能的測試報告（數據庫版） InPractice 2005-09-25 20:32
在同一個事務中，流程1和流程2共用一個連接應該效率較高。實踐中大家可能都沒有注意這個。因為一般是DAO和SERVICE兩層。每個DAO是獨立的，組合到Service中時也沒有特意讓兩個DAO共享同一個連接，就會出現上面的情況。
re: JSF與Struts的區別 InPractice 2005-09-24 09:32
JSF畢竟是基于JSP的，所以Page的編寫應該是比較煩瑣的。
<jia:navigatorItem name="inbox" label="InBox"
icon="/images/inbox.gif"
action="inbox"
disabled="#{!authenticationBean.inboxAuthorized}"/>
是一種進化，不必象用JSTL或者struts的Logic標簽那樣麻煩，其實Tapestry做得的更徹底，他根本上拋棄了JSP的tag。全部采用和例子中風格一致的方式實現。真正做到模板和Java代碼完全獨立。對于我這種不喜歡前臺工作的程序員來說，真是一種福音，只可惜Tapestry目前還不夠成熟。