随笔 - 53, 文章 - 0, 评论 - 3, 引用 - 0
数据加载中……

我的评论

re: 消除实现继承和面向接口编程 InPractice 2007-09-08 10:56  
我就很反感一个接口一个实现的方式。当然这是以我的项目经验为前提的(不排除目光偏狭的可能性)。
这种预留的扩展余地,即将来可以加入其他的实现。在我的项目中事实上成为了“过度工程”的例子。因为到现在为止还是一个接口一个实现。倒是每次读代码是多了一个间接级别,麻烦了很多,效率降低。有人可能争辩说,代码读起来麻烦点没有关系,设计上还是优美的。我不同意这种观点,现实中的代码读的次数远远超过写的次数,读代码效率降低的影响不是一个所谓的优美的(在我看是华而不实)设计可以弥补的。
在我看来,一个接口一个实现, 恰恰是当前流行的反模式。尽管可能在某些情况下有其合理性,但多数是对“面向接口编程”的滥用。
re: Insertion-Sort和Merge-Sort InPractice 2007-05-06 14:45  
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模式也可以实现。至于这两者之间的取舍,需要根据更具体的需求才能确定。
在同一个事务中,流程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目前还不够成熟。