场景
以列表接口为例，一般都是返回所需数据的集合以及分页信息。这通常都是一个模板类，所有列表接口都是通用的。
如果是返回给前端，那么需要泛型与否都没必要，前端看到的就是一个Object；
如果是后端使用，那么泛型就非常必要。
定义返回模板
可以看到，这两个模板类，其属性 data 都是一个List，用于封装列表数据。唯一的区别在于一个加了
Service定义
该Service定义了两个方法，都是查询用户的所有信息。
第一个方法返回对象为：ResponseList
第二个方法返回对象为：ResponseListImprove（支持泛型）
第三方调用
通过图3，我们知道UserService里有两个获取用户信息的方法。
现在第三方（其他人）在list方法里进行调用并且要使用返回的数据。
ResponseListImprove模板，返回数据只能通过User对象接收，Man类型会编译不通过。
ResponseList模板，可以将返回数据转为User或Man接收，这明显不是我们预期的结果。并且编译器也会给我们提示：Unchecked assignment: ....
好处
1.保证类型安全
使用泛型后，如果其他地方需要调用获取列表信息的方法，在使用返回数据的时候，无论是添加还是使用数据，都可以减少出错的概率。
2.消除强制类型转换
没有泛型的返回，我们可以认为是一个Object，在使用时需要对其进行强制转换，在转换过程中，非常容易出现ClassCastException。
再改进 20180122
给返回对象添加序列化
为什么要序列化？以下是百度的...
java的序列化机制是通过在运行时判断类的serialVersionUID来验证版本一致性的。在进行反序列化时，JVM会把传来的字节流中的serialVersionUID与本地实体类中的serialVersionUID进行比较，如果相同则认为是一致的，便可以进行反序列化，否则就会报序列化版本不一致的异常。
IDEA 自动生成serialVersionUID
IDEA不具有自动生成serialVersionUID的能力，所以需要安装插件 GenerateSerialVersionUID。如图：
使用方法
对象序列化后，使用Alt + Insert 即可
给泛型添加约束
Q:为什么要 T extends BaseResponseDTO？
A:保证传入数据的安全性。（BaseResponseDTO只是用于示例，正式使用看需看场景）
改造User
改造User，否则图3的UserService.findAll 编译不通过
BaseResponseDTO
BaseResponseDTO中可以抽象一些具有公共性的属性等，具体还需要看使用场景。