比如有个方法 getMembersFromGroup ，我可以设计它只接受需要的最小范围参数。比如. 只接受 groupId, getMemberFromGroup(domian, path, groupId)。我也可以设计他接受 Group 对象，比如 getMemberFromGroup(group)。第一种设计可以明确需要的参数，也方便调用。但是不方便扩展，当需要的参数的多的时候会很乱。第二种更面向对象，但是如果我要复用方法时，无法获得整个对象，不通过查看接口实现就无法了解该如何构造。对于这种问题大家是怎么看的？
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 3713 days ago, the information mentioned may be changed or developed.
 |
1
knightdf Mar 16, 2016
面向对象有个特性叫多态。。。
|
 |
2
bp0 Mar 16, 2016
传递 group 对象通常是提高耦合性。因为如果传递 group ，则 getMemberFromGroup 方法就必须依赖 group 对象提供的获取 domain ， path 和 groupId 的方法。如果这些成员是公有的，则问题更严重。
当然，如果 getMemberFromGroup 方法本身就与 group 关联性很强，那么传递 group 也是没有问题的。 另外，不是给接口传递对象才是面向对象。面向对象是一种方法论，而不是指接口的参数类型。 |
 |
4
SpicyCat Mar 16, 2016
传 id ，通过 id 再获取对象。
|
 |
6
WhoMercy Mar 16, 2016
迪米特法则（ Law of Demeter ）又叫作最少知识原则（ Least Knowledge Principle 简写 LKP ），就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。
|
 |
8
fwrq41251 Mar 16, 2016
看参数个数，参数超过三个就写成类。
|
 |
9
FrankFang128 Mar 16, 2016
改名 getMembersByGroupId
|
 |
10
siteshen Mar 16, 2016
front end 层负责把 group_id 变成 group ， logic 层参数 group, model 层参数 id 。
|
 |
11
xylophone21 Mar 16, 2016
@WhoMercy 说的是对的，具体来说，就是如果 getMembersFromGroup 所在的方法，必须认识 Group 就可以传，否则就不能传。
|
 |
12
xieguobihaha Mar 16, 2016
按照「代码大全」的建议是：如果分开传的参数刚好只是某个对象的属性，在使用这个接口时需要先 new 个对象然后填入属性，那么分开传比较合适；反之，则传对象比较合适。
|
 |
13
gkiwi Mar 16, 2016
超过 3 个就用对象吧，不过可以做一个『简单版』的对象（类似 Map ，但是做好字段规划）
===== 某年和别人联调遇到过一个 10 多个参数的函数，后来反反复复增删字段，差点日狗，最后改成用 HashMap 传了~ |
 |
14
kaizixyz Mar 16, 2016 via iPad
楼主说的这种状况，请用对象。方法的名字透露了跟 group 的强联系。
|
 |
15
billlee Mar 16, 2016
为什么不是 Group::getMembers()
|
 |
16
skydiver Mar 16, 2016
domian 23333
|
 |
17
caixiexin Mar 16, 2016 via Android
说的应该是 java 这类强类型语言吧
刚学设计模式的时候看到迪米特法则，会强迫自己遵守，使用第一种，直接定义参数列表。 后来工作时碰到的接口动则就是七八个参数，就妥协用第二种了。副作用是方法调用层级多的情况下，需要反复转换封装入参对象。据说使用 ddd 的设计模式可以减少不必要的模型转换。 现在个人偏向第二种 |
 |
18
levn Mar 16, 2016 via Android
某些语言里你可以直接同时写这两种。。。
|
 |
19
Ouyangan Mar 17, 2016
json 23333
|
 |
20
ffffwh Mar 17, 2016 via iPad
理想：直接暴露 field 不好，弄成 getter 。然后再弄个接口包含这些 getter ，目标函数接受接口。
现实：看心情随便写，以后有空重构。 |
 |
21
hardware Mar 17, 2016
**kwargs
|
 |
22
lecher Mar 17, 2016 via Android
一个接口七八个参数的时候，会很头疼，新增业务根本不敢随便改动接口参数，有时候为了新增的一两个参数就要另起新的接口做类似的业务处理。
封装对象对接口调用隐匿了参数细节，内部实现各种判空校验处理做模型转换同样很头疼，有时候不看实现不知道如何传参调用。 我习惯传对象，调用和新增业务各种省事，但是接口内部处理像一团乱麻。对外暴露的接口数量会比较少。变更数据模型的改动量小一些。 团队开发规范是参数列表，一个接口加加加就变成五六个参数，内部实现一个接口只做一件事情，需要对外暴露很多个业务相近的接口，调整数据字段的时候经常面临七八个接口的改动。 |
 |
23
yuriko Mar 17, 2016
数据多时，通过构造器生成参数包，尽可能不使用原对象
|
 |
24
Lpl Mar 17, 2016 via Android
应该是 java 的 controller 层吧(用的 springmvc)？
我们的开发规则是:当参数在四个以上时需要考虑封装成一个 formbean 对象。不然的话参数太多，代码太长 |
Select Language