kotlin - 为什么我们在Kotlin中仅使用[列表， map ，集合]集合？

Question

我一直在学习Kotlin，并且遇到过Collections API。在Kotlin之前，我一直在学习Java，并且我知道Java中有很多不同类型的Collections API。例如，我们使用List, Map, Queue, Set等代替常规的ArrayList, HashMap, LinkedList, LinkedMap。尽管在Kotlin中，我们仅使用Map, List, Set等常规类型，但也可以使用HashMap等。那么，这是怎么回事？你能帮我弄清楚吗？

Answer 1

尽管Kotlin最初的主要目标是JVM，但JetBrains大力 push 将其设置为multiplatform，并同时支持JS和Native。

如果您在JVM上使用Kotlin，则您使用的任何集合的实现仍将是原始JDK类，例如java.util.ArrayList或java.util.HashSet。 Kotlin标准库没有重新实现这些功能，它具有一些很大的好处:

这些是经过良好测试的实现，无论如何都要维护。

使用完全相同的类使与Java互操作变得轻而易举，因为您可以来回传递它们而不必执行任何类型的转换或映射。

Kotlin所做的就是以标准库接口(interface)(例如 List， Map， MutableList， MutableMap等)的形式在这些现有实现上引入自己的集合语义。一小部分的 compiler magic使得现有的JDK类也可以实现这些接口(interface)。

如果不需要特定类型的集合的特定实现，则可以通过这些接口(interface)以及标准库的相应工厂方法( listOf， mapOf， mutableListOf， mutableMapOf等)使用集合。这使您的代码更加通用，并且独立于具体的基础实现。您不知道标准库 mutableListOf函数将为您创建哪个特定类，只是它将是一个满足 MutableList接口(interface)约定的对象。

默认情况下，您基本上应该在代码中使用这些接口(interface)，尤其是在公共(public)API中:

对于函数参数，这使客户端可以向函数提供他们希望提供给您的集合的任何实现。如果您的函数可以在List上执行任何操作，则应仅请求该接口(interface)-没有理由专门要求ArrayList或LinkedList。

如果这是一个返回类型，则使用这些接口(interface)可以让您更改将来在内部创建的特定实现，而不会破坏客户端代码。您可以保证只返回一个MutableList的东西，并且支持该列表的实现不会暴露给您的客户。

如果您查看Kotlin标准库的所有 collection handling functions，您将在表面上看到它们几乎完全在这些接口(interface)上运行。如果深入研究，您会发现正在创建的 ArrayList实例，但这不会暴露给客户端代码，因为它在大多数时间不必关心具体的实现。

再回到多平台点，如果您以仅依赖Kotlin标准库定义的类型的方式编写代码，则该代码将可轻松用于非JVM目标。如果您在导入中引用 kotlin.MutableList，则可以立即编译为JS代码，因为每个平台上都有该接口(interface)的Kotlin标准库实现。无论是直接映射到现有类，以某种方式包装现有类，还是从头开始为Kotlin实施，都不必担心。但是，如果您在代码中引用 java.util.TreeSet，那么该目标将不适用于JS目标，因为那里没有Java平台类。

您还能直接使用 java.util.ArrayList这样的类吗？当然。

如果您有时看不到代码跨平台，那么直接使用Java集合是完全可以的。

如果出于性能原因需要List或Set的特定实现，则有时必须直接使用Java类。

有趣的是，在Kotlin的最新版本中，这些特定类型的实现(例如，基于数组的列表)也被包装在标准库的类型别名下，因此它们在默认情况下是独立于平台的:有关此示例，请参见 kotlin.collections.ArrayList 或 kotlin.collections.HashSet 。这些Kotlin定义的类型通常会在IntelliJ完成中首先出现，因此您会发现自己被迫尽可能使用它们。对于大多数异常(exception)情况也是如此，例如 IllegalArgumentException 。

TL; DR:您可以在Kotlin中使用两种Java类型的Kotlin集合类型，但是您应该尽可能地使用Java类型。