目前接手的项目的各个模块中存在不同的写法，有直接一个参数类覆盖全部请求的，也有使用继承的，目前第一种写法存在一个问题：
用
swagger写文档时，无法准确的标识出各个字段的required属性。如id字段在create时required属性是false，而在update中required必须是true，该文档框架不换的前提下，希望能找到一个比较合理的方式统一他们的写法。
2019/12/5
在咨询了几个人之后，综合他们的意见，对同一个模块中不同请求的参数类设计总结如下：
-
create()和update()一般来说参数之间的差异不会太大，create()往往只会比update()少一个id等标识字段。 -
list()的参数一般比这create()和update()请求的参数要复杂，因为list()中部分参数（如creator，gmt_modified等）在另外两个请求中都是通过判断等处理后直接赋值的方式传递给DTO，如gmt_modified，它们无需拥有该字段。 -
getById()可能比list()再多出部分字段，如components等。。经过以上分析，可以采用继承的手段来解决这两个请求：
创建一个参数类的基类，只拥有各个请求参数的交集，各个请求的参数类按照各自所需通过继承进行扩展。
继承方式设计示例：
applicationPage设计：
- 公共参数类
public class basePageModel{
private String title;
private String name;
private String applicationId;
private String route;
private Boolean visible;
private String parentId;
}
==此处特殊之处在于：创建时可以指定type，修改时不能指定type==
- create请求的参数类
public class createPageModel extends basePageModel{
private Integer type;
}
- update请求的参数类
public class updatePageModel extends basePageModel{
private String id;
private Integer sequence;
}
- list和getById请求的响应参数类
public class pageVO extends basePageModel{
private Long createTime;
private Long modifyTime;
private Integer type;
private Integer sequence;
private String id;
}
保存和获取详情单独创建接口并设置独立的类
- save和get详情请求的响应参数类
public class componentModel {
private String id;
private JSONObject components;
}
2019/12/6
再次讨论一翻过后，更新结论：
继承的方式会破坏扩展的灵活性，且在多人维护时造成混乱。举例说明如下：
- 破坏扩展的灵活性：
这一点主要体现在很难界定一个字段应该出现在Base中还是在其子类中，如这种场景：
假设目前需要添加一个字段，create()和list()中可用，而update()中禁止修改该字段。如果将其放在BaseModel中就会在update()中可见；如果在create()和list()中分别添加则又与我们使用继承的初衷相违背。
在这两层继承的情况下，需要部分类各自添加该字段，如果这样的字段多来几个，解决方法有两个：
-
继续抽象：如果需求再发生变化，可能这个抽象的层次会不断的增加，有点将问题复杂化的趋势
-
分别添加到对应的子类：这种情况个人认为无论是特殊字段少还是多都不如
继续抽象来得好用。特别是特殊字段多的时候用这种方式，感觉有点放弃治疗的意思，一个字段的修改都需要涉及几个类分别进行修改。
- 多人维护时造成混乱
在上面的版本上，假设有A、B两人进行开发。可能A在开发涉及到create()操作的feature时需要添加一个字段，他会直接把该字段加到CreateModel，在下一次B在进行涉及到update()的feature开发时同样会遇到加该字段的需求，假设在他知道CreateModel已经存在该字段的情况下，可能B懒得去更改之前的代码；又或者他根本就不知道CreateModel中已经存在了该字段，然后直接将该字段又加上了updateModel中。这样的话继承的实际意义就不大了。
结论
针对每个不同的请求创建不同的参数类，各个参数类根据实际需求添加字段，不使用继承保持相对独立。
