问数组作为参数的缺点是什么？

EN

数组作为一个参数非常有用，当您想要传递的东西是密切相关并且没有意义的单独。一个经典的例子是Color，它由blue、green、red (可能还有gamma)定义。将这些参数组合到数组(或javascript中的对象)中，可以轻松地将其交换出去。

总是使用数组作为函数的单个参数，这会使您脱离IDE可以提供的参数列表。对于阅读代码的人来说，找出需要传递给函数的内容是非常困难的。它也为未来的爬行打开了大门(哦，这个函数只是给我煮咖啡，但是如果我再添加一个可选的参数，它也可以给我泡茶。)也许我可以让它给我做晚餐。为什么不添加这个功能来订购攻击直升机)。

在常规参数列表中，可以通过引用传递事物(function pushElement(array &$sortableArray, $element))。如果可能的话，这在常规数组中是不被期望的。

关于默认值的点是一个无意义的点。普通参数列表允许类型提示和默认值很好：

function action(string $action = 'tickle', string $target = 'Polar bear') {
  print "I {$action} a {$target}";
}

作为数组的单个参数可能只有在传递某种静态配置时才真正发光。您可以将某些内容的配置与实际使用的代码分开，从而使修改配置变得更容易。同时，您可以利用这样一个事实:您不必按照非常具体的顺序发送20个参数。

在你的例子中，你给出的参数列表变化很大，而且很长，这意味着你的函数做的太多了。它的一部分应该被移动到构造函数中，一部分应该被移动到某种类型的Form类中。

这个话题的某些部分是非常固执己见的。

您描述的问题不仅仅是参数列表与参数序列之间的关系。有几个问题会发生(在你的例子中这两个问题)。

• 工具
• 参数排序
• 语义学

Tooling可能是显而易见的:如果您只使用数组作为参数，那么任何都不会知道内部应该是什么。好吧，大多数艾德斯都不会知道。

参数的排序通常由函数的名称和/或其语义决定。如果您是drawLine，则参数的规范顺序是($from, $to)。如果没有规范的顺序，代码可能有其他问题.(见下文)

语义：如果您有3+参数(特别是有更多的参数)，那么很可能抽象是错误的。例如，假设您有一个函数createShirt($size="m", int $red, int $blue, int $green, Image $logo, $material="wool")：属性的顺序是任意的，生成的对象(恤)可能不需要所有这些参数，但是您绝对可以使用这个抽象。我更喜欢构建器模式，例如：

$shirt = ShirtBuilder::create("m") // verifies m is a size
      ->setColor(new Color($red,$green,$blue)) // has type-hint color
      ->setImage($logo) // has type-hint
      ->setMaterial($material)
      ->build();

它绝对更冗长，但很明显，您只需调用所需的函数，就可以在任何时候验证set值(read: function调用)。build函数可以验证组合是否有效，恤对象本身甚至可以是不可变的。

然而，数组绝对有它们的位置和目的。但通常情况下，它是“提供一份同类型物品的清单”。如果您的数组只有来自一个非常小的域的字符串键，那么您可能需要一个对象。

使用对象会引发诸如“哪些参数应该属于此对象？”之类的问题。如果没有真正的参数子集出现在一起的语义原因，那么您可能需要命令模式(命令对象)。IDEs可以提供所有的奇迹，使使用这些很容易

tl;dr：

使用数组来保存异构参数列表可能是一种反模式(在某些场景/语言中可能是合理的)。

超过3个参数的函数/方法表明抽象太少(可能有原因)。使用适当的设计模式。