大家在设计接口的时候，传参一般是传逻辑上需要的最小范围还是直接传对象？

[shawncx]

比如有个方法 getMembersFromGroup ，我可以设计它只接受需要的最小范围参数。比如. 只接受 groupId, getMemberFromGroup(domian, path, groupId)。我也可以设计他接受 Group 对象，比如 getMemberFromGroup(group)。第一种设计可以明确需要的参数，也方便调用。但是不方便扩展，当需要的参数的多的时候会很乱。第二种更面向对象，但是如果我要复用方法时，无法获得整个对象，不通过查看接口实现就无法了解该如何构造。对于这种问题大家是怎么看的？

[hardware]

**kwargs

[lecher]

一个接口七八个参数的时候，会很头疼，新增业务根本不敢随便改动接口参数，有时候为了新增的一两个参数就要另起新的接口做类似的业务处理。

封装对象对接口调用隐匿了参数细节，内部实现各种判空校验处理做模型转换同样很头疼，有时候不看实现不知道如何传参调用。

我习惯传对象，调用和新增业务各种省事，但是接口内部处理像一团乱麻。对外暴露的接口数量会比较少。变更数据模型的改动量小一些。

团队开发规范是参数列表，一个接口加加加就变成五六个参数，内部实现一个接口只做一件事情，需要对外暴露很多个业务相近的接口，调整数据字段的时候经常面临七八个接口的改动。

[yuriko]

数据多时，通过构造器生成参数包，尽可能不使用原对象

[Lpl]

应该是 java 的 controller 层吧(用的 springmvc)？

我们的开发规则是:当参数在四个以上时需要考虑封装成一个 formbean 对象。不然的话参数太多，代码太长