为什么Java中的Collection类都继承了抽象类还要实现抽象类的接口

为什么Java中的Collection类都继承了抽象类还要实现抽象类的接口，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。

最近看了 Github 上很火的项目，star 超过了 vue。就想看看 github 的 star 排行榜，看完之后，我突然想到能不能看看 stackoverflow 上的排行榜。做一些翻译也很不错！

在打开 stackoverflow 的时候，突然看到一个很稀奇的问题。为什么Java中的Collection类都继承了抽象类还要实现了抽象类的接口？

Why do many Collection classes in Java extend the abstract class and implement the interface as well?

这是一个很好的问题，是一个我从来都没注意过和思考过的问题。

大致给大家翻译一下，为什么要这样做？

Java 中其实有很多集合 Collection 都有这样的神操作。比如：HashSet 继承了 AbstractSet 并实现 Set，但 AbstractSet 已经实现 Set。HashMap extends AbstractMap，AbstractMap implements Map 等。

为什么要这样做呢？根据上面的解释，其中一个很重要的原因是：规范。如果不实现对应的抽象类也不会有影响，只是实现对应抽象类后能帮助我们理解代码，而无需通过给定类的完整层次结构。

第二个，在反射上可以观察到它们的差异。比如，下面的代码：

运行后，输出下面的结果：

通过上面的结果，你会发现，List 其实 extends Collection 接口，但是 Collection 接口并没被打印出来。也就是说上面的输出不包括由超类实现的接口，也不包括作为包含的接口的超接口的接口。比如，Iterable 和 Collection 等从上面遗漏，即使 ArrayList 隐式实现它们。要找到它们，您必须递归迭代类层次结构。

幸运的是，这种差异不会影响 instanceof。比如 new ArrayList<>() instanceof Iterable 和 Iterable.class.isAssignableFrom(ArrayList.class) 结果为 true。

JDK 中的这些集合的实际设计和实现，"可读性"也是很重要的一部分。

关于为什么Java中的Collection类都继承了抽象类还要实现抽象类的接口问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注行业资讯频道了解更多相关知识。