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目前还不够成熟。