幼学琼林--SpringSide推荐的JDK5.0 feature

随着光阴推移，Annotation 慢慢在开源框架中推广，泛型渐渐被程序员们用熟，加上AutoBoxing的小糖，SpringSide终于离不开JDK5.0。

1.AutoBoxing 与 For Each 循环
    本来int的非Object性就很无聊，在JDK5.0终于提供了autoboxing功能。这个语法简化糖，被用在了每一个地方。

    for each 循环也改善了原本总要愣一下的collection遍历。不过对于非JDK基本类型，collection必须用泛型声明，如List<Book>。

2. 泛型
    泛型大量用于SpringSide Core中的基类，使子类更简洁，基类更强大。当然，基类是难读了，所以才需要社区花上这么长的时间来把<T>看到顺眼。

    泛型使用的有两个定式：

2.1 避免强制类型转换
   如果函数输入参数里含Class类型，而返回值又是该Class的实体，应该将该函数设为泛型函数。最典型的例子是HibernateGenericDao的get() 函数

public <T> T get(Class<T> entityClass, Serializable id) {
   return (T) getHibernateTemplate().get(entityClass, id);
}

  其中眼花缭乱的第一个<T>声明这是一个泛型函数，第2个T声明返回值为T，第三个Class<T>代表 T.class。基类写的辛苦，但子类用得爽快

   Book book = (Book)manager.get(Book.class,1) 简化成了 Book book = manager.get(Book.class,1);

2. 2 泛型配合反射API从T获得 T.class。
   最典型的例子HibernateEntityDao，子类只需以下定义，即获得要管理的Entity的Class。

BookManager extends BaseHibernateDao<Book>    此时子类只要声明一次T，上面的Book book = (Book)manager(Book.class,1) 就能简化成Book = manager.get(1);

    一举两得地既避免了强制类型转换，又声明了T.class 供框架使用，无须再在Manager的构造函数或getEntityClass()函数定义entityClass，。

    反射的API 详见GenricsUtils ，精简的对上面BookManager的定义反射代码如下:

Type genType = clazz.getGenericSuperclass();
Type [] params = ((ParameterizedType) genType).getActualTypeArguments();
return (Class) params[0];

  泛型反射的关键是获取ParameterizedType，再调用它的getActualTypeArguments()方法获得实际绑定的类型。但注意public class BookManager<Book>是不能被反射的，因为擦拭法的缘故。只有在Superclass 或者成员变量(Field.getGenericType())等有函数返回ParameterizedType的时候才能成功反射，，

比如

public class BookManager extends Manager<Book>{
}

public class BookAction {
    private BookManager<Book> manager;
} 

2.3 其他应用
   1. 在XFire中，List getBooksByCategory()函数返回的结果，需要用aegis.xml 文件声明List中的元素为Book.

   而如果定义函数为 List<Book> getBooksByCategory()，就不再需要声明，省掉XMl配置文件。

3.Annotation
     Annotation 大幅提升了Java的编程模式，SpringSide 目前运用的Annotation 有：

     3.1. Hibernate Annotation
         使用Hibernate Annotation 代替hbm文件，因为annotation高度的默认性，典型的POJO基本上不需要定义什么，代码的简约性和可管理性大幅提高，直追ROR。

         另外，经过测试，annotation 完全能胜任一些比较复杂的Mapping定义，如Product-Book的父子继承关系，Order-OrderItem-Product的经典三角关系。

     2. XFire JSR181 Annotation
         JSR181声明的Web Service，比原本用xml定义的模式节约了XML文件和配置代码的数量。

     3. 声明Entity类型的Annotation
         使用Annotation 声明Entity的类型，比如Udeletable，Auditable 等，比用接口声明的方式有更少的侵入性，详见 侵入，非侵入？Interface vs Annotation。

4. 三种内置Annotation
JDK5.0 有SuppressWarnings，Deprecated和Override 三种内置的annotation：

@Override
   此标签一方面提醒用户这是个重载函数，另一方面保证了父类函数的参数或者名字改变时，子类如果没有跟着变化，就会编译不过。

   虽然有点占地方，但用处的确很大，不会哪天子类被人卖了都不知道。

  所以我设置了让IDEA6检查所有重载函数必须加上@Override标识。

  @SuppressWarnings("unchecked")
    此标签可以让编译器忽略某种warning信息，比如减少JDK5.0的集合操作引入范型后无处不在的warning。

    因为有些非JDK5.0的开源库如hibernate, 函数返回的一定是List，而不会是List<User>，这时候IDE就会爆出很多warning。用SuppressWarning("unchecked")可以让IDE安静一些。

  @Deprecated
   此标签以前写在JavaDoc里，现在提到annotation，注释已废弃的函数。用户使用该函数的话，编译时会得到"你用了废柴"的提示。

5.可变参数
用于HibernateGenericDao中，简化函数接口。

比如 一个public List find(String hql, Object... values)，就支持了如下四种调用，避免了以前的煞费苦心的定义多种接口，然后把参数转成统一模式的大量重复定义。

dao.find(hql);
dao.find(hql,arg0);
dao.find(hql,arg0,arg1);
dao.find(hql,new Object[arg0,arg1])

第2个T和第3个T是不是表述错了？

有什么问题？

package org.springside.core.commons.dao;

import java.io.Serializable;
import java.util.List;

/**
 * 针对单个Entity对象的操作定义.
 * 不依赖于具体ORM实现方案.
 *
 * @author calvin
 */
public interface EntityDao<T> {

	T get(Serializable id);

[color=red]	List<T> getAll();[/color]

	void save(Object o);

	void remove(Object o);

	void removeById(Serializable id);
}

getAll()方法，放在这里是否合适？

public class OrderManager extends HibernateEntityDao<Order>

服务层类继承针对单个实体类的DAO，是否意味着服务层代码一个事务中只能更改一个实体类？
如何处理变更多个实体类的情况？

我认为应用Annotation速度确实是快了，但是将持久化和业务逻辑两个方面的东西简单混在一起，不是什么好味道。
建议采用aspectJ5中的declare annotation进行分离，在高效的同时，兼顾美观。

可以的啊，HibernateEntityDao的父类是HibernateGenericDao,里面的函数都是有Class参数。

60%以上的情况，一个Manager都只处理一个实体，另外的情况可以用带class参数的函数，或者注入另一个dao/manager .

好，学习一下aspectJ5中的declare annotation先。只是ror怎么又没人说什么dao层隔离，逻辑隔离之类的味道问题呢。Java就是太多模式了，新公司的主框架居然是6层架构.....

如果使用ActiveRecord也就没必要隔离了，但如果是ORM还是有必要吧。

俺们设计的从界面到数据访问好像也是6层。

java要快速，简便，干不过ROR，与其以己之短，攻人之长，倒不如反过来，做适用于复杂业务环境的构架。

内置的这几个Anno不错。
@Override防止子类写错名字
@SuppressWarnings("unchecked")让IDE清爽
@Deprecated清楚
Hibernate、Xfire、Compass的Anno在有IDE支持的情况下的确很爽。

DAO绑定到Entity似乎是Spring+Hibernate的时候比较惯用的，当然这么做起实只是代码横纵划分清楚，可是带来的形式化代码量大增，不爽呀。也许这时需要万能DAO，类似直接用session了。