override 和 implement

在类和接口的继承关系中，override 一个方法 表示子类 实现 父类的 那个非 abstract 的方法。

称 重写(override) 的原因就是，已经有具体的实现代码，所以称 override.

而称子类A implement 父类B 一个方法，则这个方法必然是 abstract.

称 实现(implement) 的原因就是，父类或父接口的方法是abstract，还没有任何具体的代码实现它，所以当一个类重新声明其父类的方法时，就可以称为 implement.

Set接口

1
public interface Set<E> extends Collection<E>

Set 接口继承自 Collection , 并没有声明任何专属 Set 的接口，而是将 原来的Collection接口中定义的方法，进行了 实现(implement)， 当然这个实现，并不是说通过具体代码来实现，而是对接口的语义进行了细化，方法所执行的功能进行语义增强的描述，加入了Set的特性。

通过这个例子，可以对接口进行进一步地了解：

在某个特定的领域内（例如：集合类框架），其最根本的（最顶部的）抽象（接口，Collection），往往是语义最模糊的，然后再根据领域内的特点，进一步对这个抽象，进行语义增强，使用可以适应领域内不同的抽象（例如： List, Queue, Set, Stack） 等等。

如果顶层接口抽象表达的比较好的话，对于子类别的抽象，则只需要将 顶层接口抽象 的方法进行语义即可，而不需要添加其它方法来表达（描述）这个接口，

例如：Set 接口 之于 Collection

相反的例子：Queue接口，从逻辑上讲，属于 Collection，它也继承自 Collection

1
public interface Queue<E> extends Collection<E>

但是，Collection接口已经定义的约定（方法），无法完全表达 Queue的抽象，所以 Queue 又添加自己领域内的约定：offer, remove, poll, peek 等。同时对于这个接口来说使用时候应该尽量使用 Queue 接口中方法，而不是 Collection 中的方法，因为它们太模糊了不足以表达Queue。

其实，之所以出现这种状况，也说明，接口设计的一个原则，接口的语义应该尽量模糊，尽量的通用。