在代码中，我发现：
String age = null;
String place = null;
new Employee(firstParam, secondParam, null, null, age, place);
班级员工不是我们的类，可能是从 wsdl 文件生成的，其中参数(年龄和位置(被称为alter，platz所以有人试图命名空参数以了解哪个是哪个，但这是好的做法吗？另一个问题是age和place被转换，而其他两个参数只是null但除此之外，创建具有null值的变量只是为了在下一行将其传递给构造函数是 okey 吗？
根据我的经验，当我有预生成的类 def 来公开不适合我需求的合约时，我倾向于将它们抽象到工厂方法后面(可能不是一个成熟的构建器，但取决于......(并公开重载的合约，帮助 API 用户简单地传递实际需要的任何参数。现在，关于将变量命名为null是否被认为是好的做法，我认为这是您的选择更主观的，而不是既定的模式。但是 IMO，简单地传递 null 会比只写几行额外的行来传递方法参数更干净。
此模式没有明确的是或否。它确实在某些领域很常用。
它具有明显的优势，即它引入了命名，从而使您的代码更易于阅读和维护，这总是好的，并且还减少了错误的可能性。
但它也有缺点。最大的可能是，对于读者来说，变量的意图可能并不直接清楚。误以为以后可能会使用它，从而污染您的变量范围。如果您一直使用这种模式，也可能不是很方便。
无需详细介绍，还有其他一些解决方案：
- 大多数 IDE 都有一个称为参数提示的功能
- 某些语言，如 Kotlin，具有命名参数
- 方法调用的构建器模式将引入显式命名
- 重新设计方法以不允许可选的 null 参数(有些人认为可选参数是一种不好的做法(
- 通过重载方法摆脱可选参数
除此之外，对于StackOverflow来说，这个问题可能过于基于意见，特别是因为社区中对这种模式并没有强烈的意见。
不，做这样的事情不是一个好的做法。无论如何，当您声明某些字段时，默认情况下，年龄将为 nullString age;。相反，我建议查看一些通用的构建器模式(请看@SpaceTrucker的答案(，而不是由具有 2 个以上参数的构造函数实例化。