Java开发笔记（五十八）简单接口及其实现

前面介绍了抽象方法及抽象类的用法，看似解决了不确定行为的方法定义，既然叫唤动作允许声明为抽象方法，那么飞翔、游泳也能声明为抽象方法，并且鸡类涵盖的物种不够多，最好把这些行为动作扩展到鸟类这个群体，于是整个鸟类的成员方法都可以如法炮制了。可是这种做法也带来了一些弊端，包括但不限于：
1、能飞的动物不仅仅是鸟类，还有昆虫、蝙蝠等其它动物也能飞，难不成昆虫类、哺乳动物类也要自行声明飞翔方法？这么做显然产生了重复的方法定义。不然的话，要是把飞翔方法挪到更底层的动物类，一大群动物为了不沦为抽象类都得重写飞翔方法，比如鳄鱼、大象等根本不会飞的动物也要装模作样扑腾几下，实在是滑天下之大稽。
2、除了几种常见的鸟类为大众所熟知之外，大部分鸟类其实人们一时半刻叫不出它们的名字，倘若在路上偶遇一只鸟儿，难道因为不认识它就没法描述它的模样了吗？（如果鸟类是个抽象类，外部是不能创建鸟类实例的）
3、就算给整个动物类都添加了叫唤、飞翔、游泳这些抽象方法，并且费尽九牛二虎之力把所有派生而来的子类都实现了这三个抽象方法，也不意味着万事大吉。譬如青蛙擅长跳跃这个动作，哪天程序员突发奇想要给抽象的动物类补充跳跃方法，从而支持青蛙的跳跃行为，随之而来的代价便是让动物类的所有子类都重写跳跃方法，这样也太伤筋动骨了。
综上所述，抽象类解决不了层出不穷的问题，远非什么灵丹妙药，只能用于处理符合条件的特定要求。若想真正有效应对这些刁钻古怪的挑战，还得指望新的抽象技术，在Java编程中这就是接口。接口不从属于类，而是与类平级，类通过关键字class标识，而接口通过关键字interface来标识。由于接口是作为类的辅助角色出现，因此它在结构上与类比较相似，不过也有不少不同之处，举例如下：
1、凡是类都有构造方法，即便是抽象类也支持定义构造方法，但接口不允许定义构造方法，因为接口只用于声明某些行为动作，本身并非一个实体。
2、在Java8以前，接口内部的所有方法都必须是抽象方法，具体的方法内部代码有赖于该接口的实现类来补充。因为有这个强制规定，所以接口内部方法的abstract前缀可加可不加，即使不加abstract，编译器也会默认把该方法当作抽象方法。
3、至于接口内部的属性，则默认为终态属性，即添加了final前缀的成员属性。当然这个final前缀也