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

[shawncx]

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

[knightdf]

面向对象有个特性叫多态。。。

[bp0]

传递 group 对象通常是提高耦合性。因为如果传递 group ，则 getMemberFromGroup 方法就必须依赖 group 对象提供的获取 domain ， path 和 groupId 的方法。如果这些成员是公有的，则问题更严重。

当然，如果 getMemberFromGroup 方法本身就与 group 关联性很强，那么传递 group 也是没有问题的。

另外，不是给接口传递对象才是面向对象。面向对象是一种方法论，而不是指接口的参数类型。

[shawncx]

@bp0 我说的面向对象是指通过传 group 对象封装了 group 的具体信息。。。

[SpicyCat]

传 id ，通过 id 再获取对象。

[chenps10]

@knightdf 看到你的头像之后我已经忘记想跟楼主说什么了，只想对你说 666

[WhoMercy]

迪米特法则（ Law of Demeter ）又叫作最少知识原则（ Least Knowledge Principle 简写 LKP ），就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。

[knightdf]

@chenps10 这么把持不住？

[fwrq41251]

看参数个数，参数超过三个就写成类。

[FrankFang128]

改名 getMembersByGroupId

[siteshen]

front end 层负责把 group_id 变成 group ， logic 层参数 group, model 层参数 id 。

[xylophone21]

@WhoMercy 说的是对的，具体来说，就是如果 getMembersFromGroup 所在的方法，必须认识 Group 就可以传，否则就不能传。

[xieguobihaha]

按照「代码大全」的建议是：如果分开传的参数刚好只是某个对象的属性，在使用这个接口时需要先 new 个对象然后填入属性，那么分开传比较合适；反之，则传对象比较合适。

[gkiwi]

超过 3 个就用对象吧，不过可以做一个『简单版』的对象（类似 Map ，但是做好字段规划）
=====
某年和别人联调遇到过一个 10 多个参数的函数，后来反反复复增删字段，差点日狗，最后改成用 HashMap 传了~

[kaizixyz]

楼主说的这种状况，请用对象。方法的名字透露了跟 group 的强联系。

[billlee]

为什么不是 Group::getMembers()

[skydiver]

domian 23333

[caixiexin]

说的应该是 java 这类强类型语言吧
刚学设计模式的时候看到迪米特法则，会强迫自己遵守，使用第一种，直接定义参数列表。
后来工作时碰到的接口动则就是七八个参数，就妥协用第二种了。副作用是方法调用层级多的情况下，需要反复转换封装入参对象。据说使用 ddd 的设计模式可以减少不必要的模型转换。
现在个人偏向第二种

[levn]

某些语言里你可以直接同时写这两种。。。

[Ouyangan]

json 23333

[ffffwh]

理想：直接暴露 field 不好，弄成 getter 。然后再弄个接口包含这些 getter ，目标函数接受接口。






现实：看心情随便写，以后有空重构。