江苏龙网

  1. 首页 > 生活 > >

Java的Collection设计是不是不太好?

你要这么说也没法反对，但这其实是一个挖坑到补救的过程，是没办法的事，那么多年前谁那么热衷于immutable啊
■网友
要不然怎么会有这么多队友来填坑呢
Java的Collection设计是不是不太好?



■网友
java不是有exception check么？
当你调用了一个会抛出异常的方法而又没有检查异常的时候
ide会提示你这里有问题
你该不会是没有用ide吧？


■网友
题主所说的这个情况我很早就发现了，实际上我觉得这就是一个历史遗留问题；拿到现在看就是一种设计缺陷。不可变集合以前是非常不流行的（即使是现在的Java代码，不可变+fp风格也是很少见的），API设计之初根本没有考虑到这一点，而设计这些返回不可变集合的API的时候并没有考虑到这一点语义不一致的情况，只是为了性能做了妥协实现成了不可变，而后来即使想改，考虑到兼容性也是没办法动这些API的，更别说重新设计集合的interface的结构了。这种情况只能开发人员依靠经验避开这种坑。
■网友
本文档回答有关Java集合框架设计的常见问题。它源自collections-comments别名上的大量流量。它用作集合框架的设计依据。核心接口-一般问题为什么不直接在核心集合接口中支持不变性，以便可以取消可选操作（和UnsupportedOperationException）？这是整个API中最具争议的设计决策。显然，非常需要静态（编译时）类型检查，这是Java中的规范。如果我们认为它是可行的，我们将予以支持。不幸的是，为实现此目标而进行的尝试会导致接口层次结构的爆炸式增长，并且无法成功消除对运行时异常的需求（尽管它们大大减少了运行时异常）。Doug Lea编写了一个受欢迎的Java Collections程序包，该程序包确实反映了其接口层次结构中的可变性区别，但基于他的Collections程序包的用户体验，他不再认为这是一种可行的方法。用他的话（来自个人通信）“让我很难说的是，强静态类型不适用于Java中的集合接口。”为了详细说明问题，假设您想将可修改性的概念添加到层次结构中。您需要四个新接口：ModifiableCollection，ModifiableSet，ModifiableList和ModifiableMap。以前简单的层次结构现在变成了混乱的层次结构。另外，您需要一个新的Iterator接口以用于不可修改的Collection，其中不包含remove操作。现在您可以取消UnsupportedOperationException吗？不幸的是没有。考虑数组。它们执行大多数List操作，但不执行删除和添加操作。它们是“固定大小”列表。如果要在层次结构中捕获此概念，则必须添加两个新接口：VariableSizeList和VariableSizeMap。您不必添加VariableSizeCollection和VariableSizeSet，因为它们与ModifiableCollection和ModifiableSet相同，但是出于一致性考虑，您可能仍选择添加它们。另外，您还需要各种不支持添加和删除操作的ListIterator以及无法修改的List。现在，我们有多达十个或十二个接口，外加两个新的Iterator接口，而不是原来的四个。我们完了吗？没有。考虑日志（例如错误日志，审核日志和可恢复数据对象的日志）。它们是仅追加的自然序列，支持所有列表操作，除去和设置（替换）除外。他们需要一个新的核心接口和一个新的迭代器。与不可变集合相比，不可变集合又如何呢？（即，客户端无法更改的集合，并且由于其他任何原因也不会更改）。许多人认为这是最重要的区别，因为它允许多个线程同时访问集合而无需同步。将这种支持添加到类型层次结构中还需要四个接口。现在我们有多达二十个左右的接口和五个迭代器，并且几乎可以肯定的是，实际上仍然存在一些集合，这些集合并不完全适合任何一个接口。例如，Map返回的集合视图是自然的仅删除集合。另外，有些集合会根据其值拒绝某些元素，因此我们仍然没有消除运行时异常。说完一切后，我们认为通过提供很少的一组核心接口（可能抛出运行时异常）来回避整个问题，这是合理的工程折衷方案。https://docs.oracle.com/javase/8/docs/technotes/guides/collections/designfaq.html


推荐阅读


上一篇：怎样压榨员工

下一篇：土建老八校大三土木猛男恋上IT，究竟何去何从