Perplexity about the parameters of java method

    /***/
    @RequestMapping("/listByRoleId")
    public CommonResult<List<MenuVo.ListByRoleIdVo>> listByRoleId(@Valid MenuParam.ListByRoleIdParam param){
        return menuService.listByRoleId(param);
    }
    @Data
    public static class ListByRoleIdParam {
        @NotNull(message = "")
        private Integer roleId;
    }
    @Data
    public static class ListByRoleIdVo {
        private Integer menuId;
        private String name;        //
        private Integer pid;        //id
    }

I now use the above form to write code in my project. The parameters of each method are defined as a class. The return value of the method is also defined as a class.
the main reason for writing this is to use valid for parameter verification, and encapsulating the parameters into an object is also convenient to use reflection to call the method.

this will lead to a lot of classes with such parameters and return values in the project.
I would like to ask that this writing gives more points about the definition of the class. what else is wrong with it? Will it affect performance?

Feb.28,2021

is obviously too clever, the modification logic should redefine the class, and the serialization cache of the class should also consider the version compatibility during the upgrade.
depends on how many, dozens of words do not care too much. The advantage is strong type validation.

if there are many, it is recommended to use abstract Map to store parameters. This separates parameters from logic.


less than 3 parameters are passed with url, and more than 3 are passed with objects


if there is such a requirement, you have to write a string of JSON parsing code instead of the corresponding data class for the specific API parameters, which is a better way to write classes.
you can also consider using GraphQL to design the parameters of the interface, but you should also write Scheme, but it is more flexible


thanks for the invitation.
there are many classes with such parameters and return values . In fact, you should write this even if you don't do verification. Parameters are encapsulated as objects, of course, but many classes can be done in an abstract and inherited way in the case of business duplication. Because of the business requirements, there are a variety of verifications, and the bean of the code becomes more and more. In fact, it doesn't matter. It just wants to be easy to maintain.

Menu