【读书笔记】Java的4个不良用法及对策

原文链接: http://www.javaworld.com/javaworld/jw-07-2008/jw-07-harmful-idioms.html?page=1

Four harmful Java idioms, and how to fix them

[b]1. 区分fields, local variables and method arguments.[/b]

作者提议：
* Method arguments are prefixed with a
* Fields are prefixed with f
* Local variables have no prefix at all

例子：
public boolean equals (Object aOther) {
if (! (aOther instanceof Range)) return false;
Range other = (Range) aOther;
return fStart.equals(other.fStart) && fEnd.equals(other.fEnd);
}

这样可以增加code的可读性。尤其是在method或者class比较长的时候。
（其实在比较现代的IDE里，这三种变量是可以给以不同的语法着色的。）

[b]2. 用package-by-feature 来代替package-by-layer。[/b]
A common way of dividing up an application is package-by-layer:
* com.blah.action
* com.blah.dao
* com.blah.model
* com.blah.util

An alternate style is package-by-feature:

* com.blah.painting
* com.blah.buyer
* com.blah.seller
* com.blah.auction
* com.blah.webmaster
* com.blah.useraccess
* com.blah.util

也就是说，把package理解为最高级别的抽象，class都是这个抽象的不同层次的实现。
把一个抽象的实现组织在一起也就理所当然了。这个package里包含需要实现这个feature的一切资源，不仅仅是Java source code。
原文是这么说的：
Here, items are not grouped according to their behavioral style. Instead, the behavior of individual classes is treated as an implementation detail, and classes are grouped according to the highest possible level of abstraction -- the level of the feature -- wherein all items related to a feature (and only to that feature) reside in one and the same package.

还提到了一个检验的方法：“删除测试” -- 移除一个feature应该只需要删除一个package。
In package-by-feature, the ideal is to pass the deletion test: you should be able to delete a feature by deleting a single directory, without leaving behind any cruft.

For example, in a Web application, the com.blah.painting package might consist of these items:

* Painting.java: A model object
* PaintingDAO.java: A data access object
* PaintingAction.java: A controller or action object
* statements.sql: The SQL statements used by the DAO
* view.jsp: The JSP used to render the result to the user


[b]3. 用immutable objects代替JavaBeans。[/b]
其实，JavaBeans的定义已将其应用限制在一个非常特殊的领域--GUI widgets。
The JavaBeans specification was created for a very particular problem domain: that of manipulating graphical widgets at design time.

作者在文章后的问答中指出：
通常，JavaBeans适合于desktop apps，而Immutable objects适合于web apps。
（Immutable Model Objects seem to be fairly natural for web apps, but less natural for desktop apps.）

Immutables are less natural for desktop apps, because the user often needs to edit many items at once, and have all those edits applied en masse. If you need to apply edits all at once, then yes, using immutables is indeed a problem.
But for web apps, immutable Model Objects form a more natural default style.

在web apps中，Server发送一个object给client用于显示，然后client修改之后生成一个新的object并返回给Server用来更新。

Q1: Isnt the expense of creating so many new objects (a new object created for every field value change) offsetting the gains of immutability in this case?
A1： For the case of a web app, the cost of creating a new Model Object for each request is usually trivial.

Q2: Is there a better way of applying immutability in this situation?
A2： To get a better understanding, you could down load the free example application that comes with the web4j tool that I built.
http://www.web4j.com/Download.jsp

[b]4. 把Private members放到后面。[/b]

通常，private members被放在class的前面。例如：
ublic class OilWell implements EnergySource {
private Long id;
private String name;
private String location;
private Date discoveryDate;
private Long totalReserves;
private Long productionToDate;

public Long getId() {
return id;
}
public void setId(Long id) {
this.id = id;
}

//..elided
}
作者指出：placing private items last, not first, seems to show more compassion for the reader.

Java之所以采用private在前面的方式，是因为早先的C++是这样的。不过C++社区已经更正了这个问题，而Java社区却没有及时更正。很大程度上是因为SUN发布的Coding Conventions缺乏管理了，而且SUN内部也不使用这个。

Ordering is: public, protected, private。

最合理的组织方式应该是：
constructors放在最前面，然后是non-private methods，最后是private fields和private methods。

It seems best to arrange code to imitate the same order used by Javadoc: first the constructors, then non-private methods, and finally private fields and methods. That's the only style in which the reader moves naturally from a higher to a lower level of abstraction.