返回ImmutableMap还是Map更好？

假设我正在写一个应该返回Map的方法。例如：

public Map<String, Integer> foo() {
  return new HashMap<String, Integer>();
}

考虑了一段时间后，我决定创建该地图后就没有理由对其进行修改。因此，我想返回一个ImmutableMap。

public Map<String, Integer> foo() {
  return ImmutableMap.of();
}

我应该将返回类型保留为通用Map，还是应该指定要返回ImmutableMap？

从一方面来说，这正是创建接口的原因。隐藏实施细节。
另一方面，如果我这样保留它，其他开发人员可能会错过这个对象是不可变的事实。因此，我不会实现不可变对象的主要目标。通过最小化可以更改的对象数量来使代码更清晰。更糟糕的是，过了一会儿，有人可能会尝试更改此对象，这将导致运行时错误（编译器不会对此发出警告）。

• 如果您正在编写面向公众的API，并且不变性是设计的重要方面，那么我绝对可以通过使方法的名称清楚地表示返回的地图将是不变的，或者通过返回的具体类型来明确指出它的地图。在我看来，在javadoc中提及它还不够。

  由于您显然使用的是Guava实现，因此我查看了该文档，它是一个抽象类，因此确实为您提供了实际的具体类型的灵活性。

• 如果您正在编写内部工具/库，则只返回一个简单的库就可以接受。 Map。人们会知道他们正在调用的代码的内部结构，或者至少可以轻松访问它们。

我的结论是，明确的是好的，不要让事情碰运气。

您应该将其ImmutableMap作为返回类型。Map包含未通过实施支持的方法ImmutableMap（例如put），并标注@deprecated在ImmutableMap。

使用不推荐使用的方法将导致编译器警告，并且当人们尝试使用不推荐使用的方法时，大多数IDE都会发出警告。

此高级警告比运行时异常更可取，因为它是您第一个暗示错误的提示。

另一方面，如果我将其保留为这样，其他开发人员可能会错过该对象是不可变的事实。

您应该在javadocs中提到它。您知道，开发人员确实会阅读它们。

因此，我不会实现不可变对象的主要目标。通过最小化可以更改的对象数量来使代码更清晰。更糟糕的是，过了一会儿，有人可能会尝试更改此对象，这将导致运行时错误（编译器不会对此发出警告）。

没有开发人员会发布未经测试的代码。当他进行测试时，他会抛出一个异常，不仅查看原因，而且查看试图写入不可变映射的文件和行。

不过要注意，只有Map自身是不可变的，而不是其中包含的对象。

如果我将其保留下来，其他开发人员可能会错过这个对象是不可变的事实

没错，但是其他开发人员应该测试他们的代码并确保将其覆盖。

不过，您还有2个解决方案：

• 使用Javadoc

  @return a immutable map

• 选择一个描述性的方法名称

  public Map<String, Integer> getImmutableMap()
  public Map<String, Integer> getUnmodifiableEntries()

  对于具体的用例，您甚至可以更好地命名方法。例如

  public Map<String, Integer> getUnmodifiableCountByWords()

你还能做什么？！

您可以返回一个

• 复制

  private Map<String, Integer> myMap;
  
  public Map<String, Integer> foo() {
    return new HashMap<String, Integer>(myMap);
  }

  如果您希望很多客户端会修改地图，并且只要地图仅包含一些条目，则应使用此方法。

• CopyOnWriteMap

  当必须处理
  并发时，通常使用写时复制收集。但是，由于CopyOnWriteMap在可变操作（例如，添加，删除）上创建了内部数据结构的副本，因此该概念也将为您提供帮助。

  在这种情况下，您需要在映射周围使用一个精简包装，将所有方法调用委托给基础映射（可变操作除外）。如果调用了变异操作，它将创建基础映射的副本，所有其他调用都将委派给该副本。

  如果您希望某些客户端将修改地图，则应使用此方法。

  可悲的是Java没有这样的CopyOnWriteMap。但是您可能会找到第三方或自己实施。

最后，您应该记住，地图中的元素可能仍然是可变的。

绝对返回一个ImmutableMap，理由是：

• 方法签名（包括返回类型）应该是自记录的。评论就像客户服务：如果您的客户需要依靠它们，则您的主要产品有缺陷。
• 什么是接口还是类仅在扩展或实现它时才相关。给定一个实例（对象），在99％的时间内，客户端代码将不知道或不在乎某个对象是接口还是类。首先，我假设ImmutableMap是一个接口。只有单击链接后，我才意识到这是一堂课。

这取决于类本身。番石榴的ImmutableMap目的并不是成为可变类的一成不变的观点。如果您的类是不可变的，并且具有某种基本上是an的结构ImmutableMap，则将其设为return类型ImmutableMap。但是，如果您的班级是可变的，那就不要。如果您有这个：

public ImmutableMap<String, Integer> foo() {
    return ImmutableMap.copyOf(internalMap);
}

番石榴每次都会复制地图。太慢了 但是如果internalMap已经是ImmutableMap，那就完全可以了。

如果不将类限制为ImmutableMapreturn，则可以Collections.unmodifiableMap这样返回：

public Map<String, Integer> foo() {
    return Collections.unmodifiableMap(internalMap);
}

请注意，这是地图的不变视图。如果internalMap更改，的缓存副本也将更改Collections.unmodifiableMap(internalMap)。但是，对于吸气剂我还是比较喜欢。

这并不能回答确切的问题，但是仍然值得考虑是否应该返回地图。如果映射是不可变的，则要提供的主要方法基于get（key）：

public Integer fooOf(String key) {
    return map.get(key);
}

这使API更加紧密。如果确实需要映射，则可以通过提供条目流将其留给API的客户端：

public Stream<Map.Entry<String, Integer>> foos() {
    map.entrySet().stream()
}

然后，客户端可以根据需要制作自己的不可变或可变映射，或将条目添加到自己的映射中。如果客户端需要知道该值是否存在，则可以返回optional：

public Optional<Integer> fooOf(String key) {
    return Optional.ofNullable(map.get(key));
}

不可变地图是地图的一种。因此，保留Map的返回类型是可以的。

为了确保用户不修改返回的对象，方法的文档可以描述返回对象的特征。

可以说这是一个见解，但是更好的主意是为Map类使用接口。该接口不需要明确地说出它是不可变的，但是如果您在接口中不公开父类的任何setter方法，则消息将是相同的。

看一下以下文章：

安迪·吉布森