万能的分页类

万能的分页类

关于对万能的分页类的想法，对于前端传送过来的分页查询我们总是要规定相应的类，而且这个类包含了分页的属性和参数。从软件工程和开发的角度来看，分页的参数是一个整体的分页类，而其他的关于这个查询条件一般也可以分装成一个类，通常我们会通过继承的方式 查询条件的类继承分页类来组成我们现在的这个包含分页信息和查询条件的类，在实现上这个是没有问题的，但是在逻辑上这似乎又有点不合理，分页参数类和条件参数类并不存在继承的关系而且分页参数类是可以独立与条件查询参数类之外的。他们两个如果真的要组成一个分页条件条件查询类应该是一种聚合关系。两种类应该都是属于分页条件条件查询类的一个私有的变量，两个类是属于同级的关系，这样我们的逻辑似乎就明白了些，至于为什么继承在常理上也是经常使用的方式是因为 对于得到的结果上 继承得到的结果大致是等同于将分页参数类和条件查询参数类变成一个分页条件查询类的两个私有变量。是因为我们只要结果 而继承的结果是等于聚合的结果所有我们平常也会这样使用。但是继承的结果在某种方式上和聚合也是有很大区别的。
例如
这个时候有三个类 参数类1 参数类2 分页参数类
我们如果要将这三种类组成一个分页条件查询类还是使用继承的方式的话 我们就需要多继承的方式（不针对语言）或者连续继承的方式
分页条件查询类 extends 参数类1，参数类2，分页参数类
或者 参数类1 extends 参数类2 分页参数类 extends 参数类1
这样一看就感觉出来这是很奇怪的逻辑关系虽然也能实现。
但是用聚合的关系
将 参数类1，参数类2，分页参数类变为 分页条件查询类的私有变量
我们发现这种逻辑关系是让人很舒服而且很容易适应的。如果以后还要参数类要加进来，我们就可以在破坏原有的类关系结构的情况下进行类的更改和扩展。
上面认识了如何实现分页条件查询类那么我们就可以开始仔细想一想怎么扩展万能的类
对于分页的参数我们是已经是一个固定的类了，而对于条件查询的类我们是不固定的。我们可以将这个不固定的类作为一个泛型。而接口接收来的是一串json的字符串，我们只需要将分页参数类转化为分页参数类的对象，而将传进来的其他的条件查询类根据泛型转换为泛型的类即可，但是常规的JSON转为固定的泛型是无法转换的他们只会转换类的第一个层级（类的变量为第一个层级 类的变量的属性为第二个层级这样依次往下），而不会往下深入的去将JSON的第二层级转为换类。JSON转换时提供了这样一个接口的可以深入的去转化JSON，同时我们将前端的接收来的JSON转化为相应的类这一步是mvc来自动给你完成的MVC 给你提供的这种转化方式只能转化到第一个层级，所以两种方式就出来了 一个改mvc的接收转换方式，二是mvc只改第一层级，剩下来的自己改。