纠结于service层中函数入参的两种方式

毫无疑问2

效果都差不多 只是一个简洁点一个多了点 自己开发的话传数组没啥问题，因为你写的大概知道参数，如果是协同开发的话那就老实选传个参，别给别人挖坑

如果是比较复杂的参数，而且有可能会动态添加的话，是不是用类来传递比较好？类似于java的bean这样子

如果是编写底层代码，第一种规范，业务代码第一种没必要，而且回头再看调用方法的代码的时候根本不知道参数的每项啥意思，感觉很乱，第二种约定好写好注释就行了

《重构·改善既有代码的设计》— 过长的参数

个人更偏向把这些参数设计成类属性，再配上 getter/setter 虽然这样看起来类本身就有点儿啰嗦了

dto

abstract public function exampleFunctionName(string $name, int $age, ...$extra_params):void;

可以做链式调用，类似DB这种

定义一个 order 模型传进来不就完事了

我们公司现在更偏向于第二种。

两种方式都不好，根据业务需求分解成多个对象，分别组装，最后传入，比如10个参数变成3个对象这样。参数过多的问题是，难以理解和维护。

dto

我觉得两种都不是很好，第一种参数过多且过于分散（如出发地和目的地可以合并为两个参数，将经纬度包在一起），第二种虽然参数少了，但是对于调用者来说构建 params 数组比较耗费心智，如果不了解业务，只能去读 Service 层的逻辑来来构造 params 数组，代码简单的话还好，如果有几百行，且分布于多个文件中……

我的建议： 将订单所需参数归类，定义为 Class，例如：

class Coordinate {
    public float $latitude;
    public float $longitude;
}

class InitOrderInput {
    public Coordinate $original;
    public Coordinate $destination;
    public string $requestTime;
    public integer $serviceType;
    public string $comment;
}

public function initialOrder(User $user, InitOrderInput $input) {}

这样调用者构造的时候，即便不了解业务也能构造出准确的入参。

不建议传参过长~

都不建议 传个对象进来就行 :unamused: 可以参考下py的 dataclass