命名空参数答案

【问题标题】：Naming null parameters命名空参数
【发布时间】：2020-01-19 11:05:32
【问题描述】：

在我找到的代码中：

String age = null;
String place = null;
new Employee(firstParam, secondParam, null, null, age, place);

Class Employee 不是我们的类，可能是从 wsdl 文件生成的，其中参数（年龄和地点）被称为 alter、platz 所以有人试图命名空参数来知道哪个是哪个，但这是一个好习惯吗？另一个问题是 age 和 place 被翻译，而其他两个参数只是 null 但除此之外，创建具有 null 值的变量只是为了将其传递给构造函数的下一行是否可以？

【问题讨论】：

你考虑过建造者模式吗？
类似的东西不一定是源代码的工作，而是IDE的工作。大多数主要的 IDE，如 Intellij，都有一个称为“参数提示”的功能。它们在方法调用中显示参数名称的位置，如果从传入的参数或方法名称中不明显（如在setName(name) 中不会显示）。如果您启用此功能，此问题将完全消失。
@Zabuza 完全正确，我们的 IDE 显示参数名称，但问题是它不是“我们的”构造函数，它是自动生成的，并且名称是德语，没有多大帮助。
@Zabuza 不需要，除非您从 IDE 中读取代码，例如在代码审查期间。
或者使用具有命名参数的语言，比如 Kotlin。

标签： java design-patterns

【解决方案1】：

根据我的经验，当我预先生成的类定义暴露了不适合我需要的合同时，我倾向于将它们抽象到工厂方法后面（可能不是一个成熟的构建器，但取决于..）并暴露重载帮助 API 用户简单地传递实际需要的任何参数的合约。现在关于将变量命名为 null 是否被认为是好的做法，我认为这对您的选择更为主观，而不是既定的模式。但是 IMO，简单地传递 null 比编写几行额外的行来传递方法 args 更干净。

【讨论】：

【解决方案2】：

这种模式没有明确的是或否。它确实在某些领域很常用。

它有一个明显的优势，它引入了命名，从而使您的代码更易于阅读和维护，这总是好的，也减少了错误的可能性。

但它也有缺点。最大的可能是，对于读者来说，变量的意图可能并不直接清楚。认为它可能会在以后使用，从而污染您的变量范围。如果您一直使用这种模式，也可能不太方便。

不说太多细节，还有一些其他的解决方案：

大多数 IDE 都有一个称为参数提示的功能
一些语言，比如 Kotlin 有命名参数
方法调用的构建器模式将引入显式命名
重新设计方法以不允许可选的空参数（有些人认为可选参数是一种不好的做法）
通过重载方法去除可选参数

除此之外，对于 StackOverflow，这个问题可能过于基于意见，尤其是因为社区中对这种模式并没有真正的强烈意见。

【讨论】：

【解决方案3】：

不，这样做不是一个好习惯。无论如何，当您声明像这样的一些字段时 String age; ，默认情况下年龄将为空。相反，我建议查看一些 generic builder patterns（请查看 @SpaceTrucker 的答案），而不是通过具有超过 2 个参数的构造函数进行实例化。

【讨论】：

不，不会的。这仅适用于字段。不适用于局部变量。
确实如此。我的错，我也在考虑 fields，而是写了 variables。
你有任何资源支持你的“不是一个好的做法”吗？这很常见，有些人倾向于不同意。这种模式可以显着提高可读性并减少错误，以防 IDE 中没有参数提示功能。