一个方法很多参数，算是好的设计还是不好的设计

[awesomePower]

如题，一个方法含有十几个参数，这算是糟糕的设计还是好的设计，还是无所谓。 有这方面的标准么？

[Rache1]

@HackerJax #8 PHP 8.0 开始也支持像 Py 那样的命名参数了

[yanqing07]

@maokg #2 四个还好吧。五个参数我接受不了，IDE 提示要用滚动条了

[adoal]

平行的十几个参数，大概率是没设计好。至少应该按照参数的业务亲密性分组，封装到结构类型里。而且，很有可能，这个接口可以做拆分成更细的接口，或者对调用逻辑做重组设计。

[0xD800]

不好的设计，应该放到一个结构体里面，否则接口签名变动的时候就抓狂了

[Rorysky]

封装在参数对象里

[miaotaizi]

你确定你的场景都会把十几个参数都传吗?

要不整理一下场景, 把函数重载一下?

[wqhui]

有时候可以选择用个对象装载所有字段，也可以选择拆出来每个字段传参

一般情况下，如果对象有 20 个字段，但方法只用到了其中 5 个，我倾向于只传这 5 个用到的字段，而不是整个对象丢进去，主要是为了明确这个方法只会被这几个字段影响运行，而不需要看方法具体逻辑。当然不嫌麻烦的话，为这个方法新建一个传参的对象装这 5 个字段也 ok ，参数多的话建议后者

[Cabana]

哈哈, 写 Compose 的已经麻木了~

[aolifu]

之前看过一个 OP 发的帖子，说是他们有的方法一百多个参数，我都惊了 /🤦‍♂️

[Sfilata]

我觉得主要看这个方法很多参数是不是有默认值。如果说正常使用，我可以只传一两个参数就可以使用通用功能，需要微调可以传特定的参数来改变行为的话，我觉得就是一个很好的设计。而且我感觉很多 shell 命令就是这么干的。

[UIXX]

代码结构设计是一种平衡艺术，天平的两端可以是易调用性和易调试性。

当然可以将几百个参数封装成大众接受数量的结构体，但这同时意味参数层级+1 ，在没有额外针对该结构的接口时，我更倾向于将它展开，除了更清晰的逻辑以及奥卡姆剃刀原则之外，显式地强调其中某些参数的用法也是这样设计的重要原因。

[lonelee]

java 代码的话是不好的设计，
kotlin 代码使用默认值+参数名指定完全没问题

[yb2313]

喜欢多, 那就写**kwargs

[xz410236056]

所以现在新语言都有可变参数的设计，调用的时候你想传什么传什么

[xueling]

太多参数不好，完全没有复用性。

[NoOneNoBody]

类方法没所谓，通过设计模式或者继承、抽象就能固定某些参数了
参数太多难点是逻辑，里面估计很多判断
底层的基础类参数多些能兼顾不同的“状态”，专用的符合业务模型的就继承基础类固定参数

[opengps]

这是按需，没法去界定啥。当然针对具体业务可能有更优的方案

[9c04C5dO01Sw5DNL]

@aolifu 有代码吗，看看

[tairan2006]

一般是不好的，不过有默认值的话有时候也可以，主要看还能不能保持常规情况下使用较为简单

[debuggeeker]

参数多不是问题，把每个参数注释写清楚就行