作者：手机用户2702935897 | 来源：互联网 | 2023-12-12 19:17
本文讨论了Kotlin中扩展函数的一些惯用用法以及其合理性。作者认为在某些情况下，定义扩展函数没有意义，但官方的编码约定支持这种方式。文章还介绍了在类之外定义扩展函数的具体用法，并讨论了避免使用扩展函数的边缘情况。作者提出了对于扩展函数的合理性的质疑，并给出了自己的反驳。最后，文章强调了在编写Kotlin代码时可以自由地使用扩展函数的重要性。
我看到 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 的所有扩展名”。
来源
我将感谢任何普遍接受的来源/参考解释为什么将函数移动为类的成员和/或实用参数支持这种分离更有意义。
回答
关于自由使用扩展函数的引用，我很确定意味着自由使用它们而不是顶级非扩展函数（而不是使它成为成员函数）。这是说，如果顶级函数在概念上适用于目标对象，则更喜欢扩展函数形式。
我之前曾搜索过为什么在处理拥有源代码的类时可能选择将函数作为扩展函数而不是成员函数的答案，但从未从 JetBrains 找到规范的答案。以下是我认为您可能会遇到的一些原因，但有些原因很受意见的影响。
- 有时您需要一个函数来操作具有特定泛型类型的类。想想
List.sum()，它仅适用于 Lists 的子集，而不适用于 List 的子类型。
- 接口可以被认为是契约。对接口执行某些操作的函数在概念上可能更有意义，因为它们不是合同的一部分。我认为这是 Iterable 和 Sequence 的大多数标准库扩展函数的基本原理。如果您认为数据类几乎像一个被动结构，则类似的原理可能适用于数据类。
- 扩展函数提供了允许用户伪覆盖它们的可能性，但强制它们以独立的方式进行。假设你
asXyzFormat()是一个开放的成员函数。在其他一些模块中，您收到 AddressDTO 实例并希望以您期望的格式获取它们的 XYZ 格式。但是您收到的 AddressDTO可能已被覆盖asXyzFormat()并为您提供了一些意想不到的东西，所以现在您不能信任该功能。如果您使用扩展功能，那么您允许用户asXyzFormat()用适用于该空间的内容替换他们自己的包中的内容，但您始终可以信任asXyzFormat()源包中的功能。
- 与接口类似，具有默认实现的成员函数会邀请用户覆盖它。作为接口的作者，您可能需要一个可靠的函数，您可以在该接口上使用具有预期行为的函数。尽管最终用户可以通过重载将您的扩展隐藏在他们自己的模块中，但这不会影响您自己对该功能的使用。
就其价值而言，我认为当您拥有类（而不是接口）的源代码时，很少会选择为类（而不是接口）制作扩展函数。我想不出标准库中的任何例子。这让我相信编码约定文档在包括接口的自由意义上使用“类”一词。
京公网安备 11010802041100号