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