今天在看线程池的源码的时候，观察到了一个之前没有关注的地方：接口继承接口
举例如下：
线程池接口：
线程池服务接口：
可以看到ExecutorService接口继承了Executor接口，而且里面也没有实现execute方法，以往没碰到这种情况。
所以到网上查了下，发现这是一种非常常见的方法，在设计JDK的时候经常用到。
接口是一种高度的抽象，里面会规定一些将要实现的行为或者只作为一种标记，如java中的Serializable接口，它比抽象类更加抽象。
继承就是泛化。在由接口组成的继承层级中，从上往下看，是由抽象到具体的过程。通过继承我们可以保留父接口中定义的行为，同时对其可以做扩展
整个继承层级，其实是类似树结构的，树的层级越深，行为就更越复杂，能做的事情就更多。上一层是对下一层共性的抽象，下层是对上层不同维度的演进。以java的集合框架为例，如下：
最开始只有一个Iterable，这里只是要返回一个迭代器，它可以用来处理一些可以迭代的对象，可以在foreach或者while循环中迭代。那么那些对象是可以迭代的呢，也就有了第二层接口，Collection、DirectoryStream都是可迭代的。接下来再往深层考虑，什么样的算是Collection，JDK中给出定义Collection代表一组对象，称之为元素，有些集合允许重复元素，有些不允许，有些有序有些无序。
根据这些描述于是又有了下一层，Set、List、Queue，这是针对Collection中不同类型的集合的抽象定义。我们发现有很多不同的方法，这个就是对Collection不同维度的演进。职责不断的细化，对于其它的接口，情况是一样的。这点和画家在创作时先画出轮廓，然后再一点一点的勾勒细节有异曲同工之妙。
接口继承有什么意义？不妨这样考虑，假如没有接口继承，会变成什么样？假如不让接口继承，那么所有接口中的方法都放到一个接口中，这是只有一个接口，那么这个接口规定的行为不觉得有点太多了么，既要负责返回一个迭代器，可以用来迭代，又要是一个集合，而且既要定义有序集合的行为，又要定义无序集合的行为，既要定义有重复元素的集合的行为，又要定义无重复元素的集合，假设只有一个方法来定义集合的行为，请为这个方法该怎么实现。千万不要说加上一大堆ifelse的判断语句，如果这时候有新的集合类型加入了，难道再加一个ifelse语句么？无疑这是一种糟烂的设计。反观通过接口继承产生的层级接口，层次分析，职责分明，Set就是Set，List就是List，想要实现那种结构直接实现对应的接口即可。换个角度看，通过接口继承，可以重新定义上层已经定义的行为，也不会影响到同一层级的其他接口中的行为。在简单的系统中，当然并不一定用到接口继承，但一个相对复杂的系统中，如JDK的集合框架，通过接口继承可以称得上是一种良好的设计。
文章为作者独立观点，不代表股票交易接口观点
股民评论