小菜提到的实体类，即项目中业务或者数据库表的映射，貌似也可以称为模型，不同的语言中叫法不同吧！！
举个例子，比如在某个Web页面中，表单上有大量的数据需要提交，如果是初学者，很可能这样接收参数：
String param1;String param2;String param3;……
这样做的坏处很多，网站空间，比如：代码会显得很乱，可能会出现大量重复代码，最主要的就是没有做到面向对象的“封装性”，导致程序不容易维护。
由此，聪明的程序员们提出了实体类的概念，也就是用类来封装业务所需要的数据。
public class User {
private String uid;
private String pwd;
public String getUid() {
return uid;
}
public void setUid(String uid) {
this.uid = uid;
}
…..
}
这样一来，我们在保存数据时，只需创建一个对象，然后通过“.”的方式来访问对象的属性，提高扩展性、提高复用性、代码简洁等等好处不言而喻。
在实际使用中，网站空间，实体类往往是和某个业务或者数据库表相对应的，看起来很简单，但随着需求的复杂化，服务器空间，业务和业务之间可能会交叉，表和表之间可能会联合查询。
这样一来，以前一一对应的实体类，便无法满足需求，因为某个实体类中可能找不到我们需要的属性，但是它却在另一个实体类中，而我们又不想随便在某个实体类中添加一个毫不相关的属性，因为这样做可能会打破类的职责单一原则。
因此，我们不得不再新建一个实体类ClassAAndClassB，这个实体类包含了类A和类B的所有属性，对于稍有经验的程序员来说，这绝对是个噩梦，因为组合的可能性是在是太多，而且可能是很多个实体组合，等待我们的将是无数的实体类，导致程序混乱不堪。
小菜一直苦于此事，今天终于通过Java的反射和泛型写了一个“联合实体类”。
通过这个联合实体类，可以把任意多个实体类融合成一个实体类。
联合实体类代码：
1 import java.lang.reflect.Method; 2 import java.util.List; * 联合实体类 杨元 7 * UniteEntity {List<Object> entitys = null;String fnName = “”;Method method = null;* 构造方法 entitys 需要联合的实体对象集合UniteEntity(List<Object> entitys){ 23this.entitys = entitys; 24 }* 获取某个取值方法 fnName 方法名称 该取值方法返回值类型 Class getFunction(String fnName){.fnName = fnName;Method m = findMethod();(m != null){Class type = m.getReturnType();method = m; type; 44}else{; 46 } 47 }* 获取某个赋值方法 fnName 方法名称 该赋值方法参数类型 Class setFunction(String fnName){.fnName = fnName;Method m = findMethod();(m != null){Class type = m.getParameterTypes()[0];method = m; type; 67}else{; 69 } 70 }* 调用某个方法，为属性赋值 <T> 赋值方法的参数类型 c value 值内容<T> void setValue(Class<T> c,T value){(Object o : entitys){{ 83 method.invoke(o, value); 84}catch(Exception ex){} 85 } 86 }* 调用某个方法，取得属性的值 <T> 取值方法的返回值类型 c 取得值的内容<T> T getValue(Class<T> c){(Object o : entitys){{ (T)method.invoke(o);101}catch(Exception ex){}102 };104 }* 从实体对象集合中查找某个方法 方法对象 Method findMethod(){(Object o : entitys){{Method[] methods = o.getClass().getMethods();(Method m : methods){(fnName.equals(m.getName())){ m;124 }125 }126}catch(Exception ex){}127 };129 }130 }变幻原是永恒，我们唯有用永恒的诺言制约世事的变幻。
