Month: June 2009

[Rod Johnson] 异步调用的两种方案:JMS和另起线程

以下是我的总结:     可以有两种办法实现异步调用        1.JMS — 功能十分强大,而且可靠性很高(比如消息的持久化)。但是这个东西复杂性很高,难维护,并且有额外的性能开销。        2.另起一个线程,在新线程里执行被调用的方法,并通过Observer模式在两个线程之间通讯。– 比较简单,实现容易。但是没有JMS的附加优点,并且集群环境下很无能。

[Rod Johnson] 框架的设计没必要太XP

他说: The XP advice of "Writing the simplest thing that could possibly work" isn ‘t always appropriate It’s impossible to refactor the interfaces exposed by a framework without breaking code that uses it and severely reducing its usefulness. Even within an organization, the cost of incompatible changes to a framework can be very large (on …

[Rod Johnson] 框架的设计没必要太XP Read More »

[Rod Johnson] 要写代码注释

我的观点和考虑到的地方几乎和他一样。但当我在javaeye论坛里表达这些观点时,别人反而觉得好笑! Remember that documentation should serve to:      1. Provide a contract for objects and methods. Test cases for an object are also valuable specifications, and documentation and test cases should be kept synchronized.      2. Save developers the trouble of needing to read code before they use it. There should be no need to …

[Rod Johnson] 要写代码注释 Read More »

[Rod Johnson] 关于 Method Visibility

1. 他说Method要的Visibility要尽量地窄,可以private的就不要把它public. 这有很多好处,不过我印象最深的是对重构的好处。的确,public方法越多,调用它的地方就可能越多,refactor时就要小心得多。 2. protected 只应该用于抽象方法上。如果具体的方法用了protected以让子类覆盖,那这就是一种concrete inheritance,这种感觉是很不舒服的。 3.包可见性的方法基本用不上,除了一种情形:该方法不是契约级的方法(实际上是private),但它又要进行单元测试。为了单元测试这个方法,可以把它置为包可见性,然后在同一个包下写它的单元测试类进行测试。 ——我不喜欢这种用法,但我承认它是封装性跟简单性的一个比较好的折衷。

[Rod Johnson] 反射会使程序变慢,但可以忽略不计

"Code that uses reflection is usually slower than code that uses normal Java object creation and method calls. However, this seldom matters in practice, and the gap is narrowing with each generation of JVMs. The performance difference is slight, and the overhead of reflection is usually far outweighed by the time taken by the operations …

[Rod Johnson] 反射会使程序变慢,但可以忽略不计 Read More »

[Rod Johnson] 关于Checked Exception和RuntimeException

基本上,Rod Johnson 对Checked Exception没有好感,一个原因是降低代码可读性,另一个原因是大部分针对Checked Exception的catch都没有用处。 SUN认为,“checked exceptions should be the norm. Runtime exceptions indicate programming errors.” Rod说他并不完全买账,随后列举了自己的一些实践。但我觉得,他自己的实践,跟SUN的官方意见基本上是一致的: Checked Exception应该代表一种业务异常,可以视为一个方法的“第二输出”。一个典型的例子就是“系统检测到取款金额大于帐户余额”。 而Runtime Exception 应该用于代表非业务的、并且Caller没办法对付的异常。举例来说,如果一个方法检测到取款金额大于帐户余额,这个方法的调用者就应该catch这个异常,并采用相应的业务策略来处理,这类异常应该是Checked Exception;但如果一个方法仅仅是检测到数据库连不上,Caller对数据库异常也没啥办法,catch它也没有任何意义 –>既然没有意义,就不要浪费代码去处理它 –>所以干脆就把这类异常做成Runtime Exception. 但是另有一个要点就是: 对Runtime Exception一定要在方法的签名处进行注释,这样Caller才知道此方法可能会抛RuntimeException,这样它就可以自己决定是否要catch这类Exception. 因为有时从健壮性或者其他因素考虑,这种catch还是有必要的。

SchemaFactory is not thread-safe

"The SchemaFactory class is not thread-safe. In other words, it is the application’s responsibility to ensure that at most one thread is using a SchemaFactory object at any given moment" See: http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/validation/SchemaFactory.html