场景

以列表接口为例，一般都是返回所需数据的集合以及分页信息。这通常都是一个模板类，所有列表接口都是通用的。

如果是返回给前端，那么需要泛型与否都没必要，前端看到的就是一个Object；

如果是后端使用，那么泛型就非常必要。

定义返回模板

图1 ResponseList 图2 ResponseListImprove

可以看到，这两个模板类，其属性 data 都是一个List，用于封装列表数据。唯一的区别在于一个加了<T>（泛型） ，一个没有。

Service定义

图3 UserService

该Service定义了两个方法，都是查询用户的所有信息。

第一个方法返回对象为：ResponseList

第二个方法返回对象为：ResponseListImprove（支持泛型）

第三方调用

图4 调用示例

通过图3，我们知道UserService里有两个获取用户信息的方法。

现在第三方（其他人）在list方法里进行调用并且要使用返回的数据。

ResponseListImprove模板，返回数据只能通过User对象接收，Man类型会编译不通过。

ResponseList模板，可以将返回数据转为User或Man接收，这明显不是我们预期的结果。并且编译器也会给我们提示：Unchecked assignment: ....

好处

1.保证类型安全

使用泛型后，如果其他地方需要调用获取列表信息的方法，在使用返回数据的时候，无论是添加还是使用数据，都可以减少出错的概率。

2.消除强制类型转换

没有泛型的返回，我们可以认为是一个Object，在使用时需要对其进行强制转换，在转换过程中，非常容易出现ClassCastException。

---

再改进 20180122

---

给返回对象添加序列化

图5 对象序列化后

为什么要序列化？以下是百度的...

java的序列化机制是通过在运行时判断类的serialVersionUID来验证版本一致性的。在进行反序列化时，JVM会把传来的字节流中的serialVersionUID与本地实体类中的serialVersionUID进行比较，如果相同则认为是一致的，便可以进行反序列化，否则就会报序列化版本不一致的异常。

IDEA 自动生成serialVersionUID

IDEA不具有自动生成serialVersionUID的能力，所以需要安装插件 GenerateSerialVersionUID。如图：

图6 IDEA->Setting->Plugins

使用方法

对象序列化后，使用Alt + Insert 即可

图7 快速生成 serialVersionUID

给泛型添加约束

图8 T extends BaseResponseDTO

Q:为什么要 T extends BaseResponseDTO？

A:保证传入数据的安全性。（BaseResponseDTO只是用于示例，正式使用看需看场景）

改造User

改造User，否则图3的UserService.findAll 编译不通过

图9 User extends BaseResponseDTO

BaseResponseDTO

图10  BaseResponseDTO

BaseResponseDTO中可以抽象一些具有公共性的属性等，具体还需要看使用场景。