Kotlin：扩展函数的惯用用法 - 将扩展函数放在它扩展的类旁边

Question

我看到 Kotlin 中扩展函数的一些用法我个人认为这没有意义，但似乎有一些指导方针“显然”支持它（解释问题）。

具体来说：在类之外（但在同一个文件中）定义一个扩展函数：

data class AddressDTO(val state: State,
                      val zipCode: String,
                      val city: String,
                      val streetAddress: String
)

fun AddressDTO.asXyzFormat() = "${streetAddress}\n${city}\n${state.name} $zipCode"

其中asXyzFormat()被广泛使用，并且不能被定义为专用/内部（也为情况下，可能）。

在我的常识中，如果您拥有代码 ( AddressDTO) 并且用法不是某个类/模块的本地（因此是私有/内部） - 没有理由定义扩展函数 - 只需将其定义为成员函数班级。

• 边缘情况：如果你想避免从get-开始的函数序列化- 注释类以获得所需的行为（例如@JsonIgnore在函数上）。这个恕我直言仍然不能证明扩展功能是合理的。

我对此的反驳是，官方 Kotlin 编码约定支持这种方式的扩展功能。具体来说：

自由地使用扩展函数。每次你有一个主要作用于一个对象的函数时，考虑使它成为一个接受该对象作为接收者的扩展函数。 来源

和：

特别是，当为与该类的所有客户端相关的类定义扩展函数时，请将它们放在定义类本身的同一文件中。在定义仅对特定客户端有意义的扩展函数时，将它们放在该客户端的代码旁边。不要创建文件只是为了保存“Foo 的所有扩展名”。 来源

我将感谢任何普遍接受的来源/参考解释为什么将函数移动为类的成员和/或实用参数支持这种分离更有意义。

Answer 1

关于自由使用扩展函数的引用，我很确定意味着自由使用它们而不是顶级非扩展函数（而不是使它成为成员函数）。这是说，如果顶级函数在概念上适用于目标对象，则更喜欢扩展函数形式。

我之前曾搜索过为什么在处理拥有源代码的类时可能选择将函数作为扩展函数而不是成员函数的答案，但从未从 JetBrains 找到规范的答案。以下是我认为您可能会遇到的一些原因，但有些原因很受意见的影响。

• 有时您需要一个函数来操作具有特定泛型类型的类。想想List<Int>.sum()，它仅适用于 Lists 的子集，而不适用于 List 的子类型。
• 接口可以被认为是契约。对接口执行某些操作的函数在概念上可能更有意义，因为它们不是合同的一部分。我认为这是 Iterable 和 Sequence 的大多数标准库扩展函数的基本原理。如果您认为数据类几乎像一个被动结构，则类似的原理可能适用于数据类。
• 扩展函数提供了允许用户伪覆盖它们的可能性，但强制它们以独立的方式进行。假设你asXyzFormat()是一个开放的成员函数。在其他一些模块中，您收到 AddressDTO 实例并希望以您期望的格式获取它们的 XYZ 格式。但是您收到的 AddressDTO可能已被覆盖asXyzFormat()并为您提供了一些意想不到的东西，所以现在您不能信任该功能。如果您使用扩展功能，那么您允许用户asXyzFormat()用适用于该空间的内容替换他们自己的包中的内容，但您始终可以信任asXyzFormat()源包中的功能。

• 与接口类似，具有默认实现的成员函数会邀请用户覆盖它。作为接口的作者，您可能需要一个可靠的函数，您可以在该接口上使用具有预期行为的函数。尽管最终用户可以通过重载将您的扩展隐藏在他们自己的模块中，但这不会影响您自己对该功能的使用。

就其价值而言，我认为当您拥有类（而不是接口）的源代码时，很少会选择为类（而不是接口）制作扩展函数。我想不出标准库中的任何例子。这让我相信编码约定文档在包括接口的自由意义上使用“类”一词。

Answer 2

这是一个反向参数\xe2\x80\xa6

\n

向语言添加扩展函数的主要原因之一是能够向标准库、第三方库和其他依赖项中的类添加功能，在这些依赖项中您无法控制代码且无法添加成员函数（ AKA 方法）。\xc2\xa0 我怀疑这主要是编码约定的该部分正在讨论的情况。

\n

在 Java 中，这种情况下唯一的选择是实用程序方法：静态方法，通常在一个实用程序类中，将许多此类方法聚集在一起，每个方法都将相关对象作为其第一个参数：

\n

public static String[] splitOnChar(String str, char separator)\npublic static boolean isAllDigits(String str)\n

\n

\xe2\x80\xa6等等，没完没了。

\n

主要问题是这样的方法很难找到（除非您已经了解所有各种实用程序类，否则 IDE 没有帮助）。 \xc2\xa0 另外，调用它们很冗长（尽管一旦静态它就改进了一点）可以进口）。

\n

Kotlin 的扩展方法在字节码级别的实现方式完全相同，但它们的语法要简单得多，并且与成员函数完全相同：它们以相同的方式编写（使用this&c），调用它们看起来就像调用成员函数一样，并且你的 IDE 会建议它们。

\n

（当然，它们也有缺点：没有动态分派、没有继承或覆盖、作用域/导入问题、名称冲突、对它们的引用很尴尬、从 Java 或反射访问它们很尴尬，等等。）

\n

所以：如果扩展函数的主要目的是在成员函数不可用时替代成员函数，那么当成员函数可用时为什么要使用它们呢？！

\n

（公平地说，您可能需要它们的原因有几个。\xc2\xa0\xc2\xa0例如，您可以使接收器可为空，这对于成员函数来说是不可能的。\xc2\xa0 但在大多数情况下，它们的重要性大大超过了适当的成员函数的好处。）

\n

这意味着绝大多数扩展函数可能是为您无法控制其源代码的类编写的，因此您无法选择将它们放在类旁边。

\n