Java接口Interface与抽象类Abstract Class

一. 面向接口编程

      在一个面向对象的系统中，系统的各类功能是由许许多多的不一样对象协做完成的。在这种状况下，各个对象内部是如何实现本身的对系统设计人员来说就不 那么重要了；而各个对象之间的协做关系则成为系统设计的关键。小到不一样类之间的通讯，大到各模块之间的交互，在系统设计之初都是要着重考虑的，这也是系统 设计的主要工做内容。面向接口编程我想就是指按照这种思想来编程吧！实际上，在平常工做中，你已经按照接口编程了，只不过若是你没有这方面的意识，那么你 只是在被动的实现这一思想；表如今频繁的抱怨别人改的代码影响了你（接口没有设计到），表如今某个模块的改动引发其余模块的大规模调整（模块接口没有很好 的设计）等等。
      Booch先生那天谈到Interaction Designer，它就是指作这类设计的人，只不过层次更高一些。我想目前咱们的软件设计队伍中，这类人是最缺少的人才之一。
      非接口编程是否是就是面向过程的编程思想？
      1.关于接口的理解
      接口从更深层次的理解，应是定义（规范，约束）与实现（名实分离的原则）的分离。咱们在通常实现一个系统的时候，一般是将定义与实现合为一体，不加分离的。实际上，系统设计规范应是全部的定义与实现分离，尽管这可能对系统中的某些状况有点繁烦。
      接口的自己反映了系统设计人员对系统的抽象理解。
      接口应有两类：第一类是对一个体的抽象，它可对应为一个抽象体(abstract class)；第二类是对一个体某一方面的抽象，即造成一个抽象面（interface）。 一个体有可能有多个抽象面，抽象体与抽象面是有区别的。
       2.设计接口的另外一个不可忽视的因素是接口所处的环境(context,environment)
       系统论的观点：环境是系统要素所处的空间 与外部影响因素的总和。任何接口都是在必定的环境中产生的。所以环境的定义及环境的变化对接口的影响是不容忽视的，脱离原先的环境，全部的接口将失去原有 的意义。
       3.按照组件的开发模型（3C），它们三者相辅相成，各司一面，浑然一体，缺一不可
       面向对象是指，咱们考虑问题时，以对象为单位，考虑它的属性及方法；面向过程是指，咱们考虑问题时，以一个具体的流程（事务过程）为单位，考虑它的实现；接口设计与非接口设计是针对复用技术而言的，与面向对象（过程）不是一个问题。
        UML里面所说的interface是协议的另外一种说法，并非指COM的interface，CORBA的interface，Java的interface，Delphi的interface，人机界面的interface或NIC的interface。
        在具体实现中，是能够把UML的interface实现为语言的interface，分布式对象环境的interface或其它什么 interface，但就理解UML的interface而言，指的是系统每部分的实现和实现之间，经过interface所肯定的协议来共同工做。
        面向interface编程，原意是指面向抽象协议编程，实现者在实现时要严格按协议来办。也就是BillJoy同志说的，一边 翻rfc，一边写代码的意思。面向对象编程是指面向抽象和具象。抽象和具象是矛盾的统一体，不可能只有抽象没有具象。通常懂得抽象的人都明白这个道理。 但有的人只知具象殊不知抽象为什么物。因此只有interface没有实现，或只有实现而没有interface者是没有用的，反OO的。
二.选择Java接口仍是抽象类
       不少人有过这样的疑问：为何有的地方必须使用接口而不是抽象类，而在另外一些地方，又必须使用抽象类而不是接口呢？或者说，在考虑Java类的通常化问题时，不少人会在接口和抽象类之间犹豫不决，甚至随便选择一种。
       实际上接口和抽象类的选择不是为所欲为的。要理解接口和抽象类的选择原则，有两个概念很重要：对象的行为和对象的实现。若是一个实体能够有多 种实现方式，则在设计实体行为的描述方式时，应当达到这样一个目标：在使用实体的时候，无需详细了解实体行为的实现方式。也就是说，要把对象的行为和对象 的实现分离开来。既然Java的接口和抽象类均可以定义不提供具体实现的方法，在分离对象的行为和对象的实现时，到底应该使用接口仍是使用抽象类呢？
      1.经过抽象类创建行为模型
      在接口和抽象类的选择上，必须遵照这样一个原则：行为模型应该老是经过接口而不是抽象类定义。为了说明其缘由，下面试着经过抽象类创建行为模型，看看会出现什么问题。
      假设要为销售部门设计一个软件，这个软件包含一个“发动机”（Motor）实体。显然没法在发动机对象中详细地描述发动机的方方面面，只能描述某些对当前软件来讲重要的特征。至于发动机的哪些特征是重要的，则要与用户（销售部门）交流才能肯定。
      销售部门的人要求每个发动机都有一个称为马力的参数。对于他们来讲，这是唯一值得关心的参数。基于这一判断，能够把发动机的行为定义为如下行为：
      行为1：查询发动机的马力，发动机将返回一个表示马力的整数。
      虽然如今还不清楚发动机如何取得马力这个参数，但能够确定发动机必定支持这个行为，并且这是全部发动机唯一值得关注的行为特征。这个行为特征 既能够用接口定义，也能够用抽象类定义。为了说明用抽象类定义可能出现的问题，下面用抽象类创建发动机的行为模型，并用Java方法描述行为1，代码以下：

public abstract Motor
{              
     abstract public int getHorsepower();              
}

       在Motor抽象类的基础上构造出多种具体实现，例如A型发动机、B型发动机等，再加上系统的其它部分，最后获得1.0版的软件并交付使用。 一段时间过去了，如今要设计2.0版的软件。在评估2.0版软件需求的过程当中，发现一小部分发动机是电池驱动的，而电池须要必定的充电时间。销售部门的人 但愿可以经过计算机查阅充电时间。根据这一要求定义一个新的行为，如图1所示。
       行为2：查询电驱动发动机的充电时间，发动机将返回一个表示充电时间的整数。
       用Java方法来描述这个行为，代码以下：

public abstract BatteryPoweredMotor extends Motor
{             
      abstract public int getTimeToRecharge();            
}

       在销售部门的软件中，电驱动发动机也以类的形式实现，但这些类从BatteryPoweredMotor而不是Motor派生。这些改动加入到2.0版软件以后，销售部门很满意。随着业务的不断发展，不久以后光驱动的发动机出现了。销售部门要求光驱动发动机须要必定光能才能运转，光能以流明（Lumen）度量。这个信息对客户很重要，由于下雨或多云的天气里，某些光驱动发动机可能没法运转。销售部门要求为软件增长对光驱动发动机的支持，因此要定义一个新的行为。
      行为3：查询光驱动发动机可以正常运转所须要的最小流明数，发动机返回一个整数。
      再定义一个抽象类并把行为3转换成Java方法，代码以下：

public abstract SolarPoweredMotor extends Motor
{              
      abstract public int getLumensToOperate();            
}

       如图1所示，SolarPoweredMotor和BatteryPoweredMotor都从Motor抽象类派生。在整个软件中，90％ 以上的代码以相同的方式对待全部的发动机。偶尔须要检查一下发动机是光驱动仍是电驱动，使用instanceof实现，代码以下：

if (instanceof SolarPoweredMotor){...}         
     if (instanceof BatteryPoweredMotor){...}

      不管是哪一种发动机，马力这个参数都很重要，因此在全部派生的抽象类（SolarPoweredMotor和BatteryPoweredMotor）中，getHorsepower()方法都有效。
      如今销售部门又有了一种新的发动机，它是一种既有电驱动又有光驱动的双重驱动发动机。光驱动和电驱动的行为自己没有变化，但新的发动机同时支持两种行为。在考虑如何定义新型的光电驱动发动机时，接口和抽象类的差异开始显示出来了。新的目标是在增长新型发动机的前提下尽可能少改动代码。由于与光驱动发动机、电驱动发动机有关的代码已通过全面的测试，不存在已知的Bug。为了增长光电驱动发动机，要定义一个新的 SolarBatteryPowered抽象类。若是让SolarBatteryPowered从Motor抽象类派生，SolarBatteryPowered将不支持针对光驱动发动机和电驱动发动机的instanceof操做。也就是说，若是查询一个光电驱动的发动机是光驱动的，仍是电驱动的，获得的答案是：都不是。
      若是让SolarBatteryPowered从SolarPoweredMotor（或BatteryPoweredMotor）抽象类派生，相似的问题也会出现，SolarBatteryPowered将不支持针对BatteryPoweredMotor（或 SolarPoweredMotor）的instanceof操做。从行为上看，光电驱动的发动机必须同时从两个抽象类派生，但Java语言不容许多重继 承。之因此会出现这个问题，根本的缘由在于使用抽象类不只意味着定义特定的行为，并且意味着定义实现的模式。也就是说，应该定义一个发动机如何得到行为的 模型，而不只仅是声明发动机具备某一个行为。

     2.经过接口创建行为模型
     若是用接口来创建行为模型，就能够避免隐含地规定实现模式。例如，前面的几个行为改用接口定义以下：
     行为1的Java代码：

public interface Motor()
{            
     public int getHorsepower();            
}

     行为2的Java代码：

public interface BatteryPoweredMotor extends Motor()
{             
      public int getTimeToRecharge();            
}

     行为3的Java代码：

public interface SolarPoweredMotor extends Motor
{             
     abstract public int getLumensToOperate();            
}

     如今光电驱动的发动机能够描述为： public DualPoweredMotor implements SolarPoweredMotor, BatteryPoweredMotor{}              

      DualPoweredMotor只继承行为定义，而不是行为的实现模式，如图2所示。
      在使用接口的同时仍旧可使用抽象类，不过这时抽象类的做用是实现行为，而不是定义行为。只要实现行为的类听从接口定义，即便它改变了父抽象类，也不用改变其它代码与之交互的方式。特别是对于公用的实现代码，抽象类有它的优势。抽象类可以保证明现的层次关系，避免代码重复。然而，即便在使用抽象类的场合，也不要忽视经过接口定义行为模型的原则。从实践的角度来看，若是依赖于抽象类来定义行为，每每致使过于复杂的继承关系，而经过接口定义行为能 够更有效地分离行为与实现，为代码的维护和修改带来方便。

三. Java接口特性学习
       在Java中看到接口，第一个想到的可能就是C++中的多重继承和Java中的另一个关键字abstract。从另一个角度实现多重继承是接口的功能之一，接口的存在可使Java中的对象能够向上转型为多个基类型，而且和抽象类同样能够防止他人建立该类的对象，由于接口不容许建立对象。
       interface关键字用来声明一个接口，它能够产生一个彻底抽象的类，而且不提供任何具体实现。interface的特性整理以下：

       1.接口中的方法能够有参数列表和返回类型，但不能有任何方法体。
       2.接口中能够包含字段，可是会被隐式的声明为static和final。
       3.接口中的字段只是被存储在该接口的静态存储区域内，而不属于该接口。
       4.接口中的方法能够被声明为public或不声明，但结果都会按照public类型处理。
       5.当实现一个接口时，须要将被定义的方法声明为public类型的，不然为默认访问类型，Java编译器不容许这种状况。
       6.若是没有实现接口中全部方法，那么建立的仍然是一个接口。
       7.扩展一个接口来生成新的接口应使用关键字extends，实现一个接口使用implements。
       interface在某些地方和abstract有类似的地方，可是采用哪一种方式来声明类主要参照如下两点：       1.若是要建立不带任何方法定义和成员变量的基类，那么就应该选择接口而不是抽象类。        2.若是知道某个类应该是基类，那么第一个选择的应该是让它成为一个接口，只有在必需要有方法定义和成员变量的时候，才应该选择抽象类。由于抽象类中容许存在一个或多个被具体实现的方法，只要方法没有被所有实现该类就还是抽象类。        以上就是接口的基本特性和应用的领域，可是接口毫不仅仅如此，在Java语法结构中，接口能够被嵌套，既能够被某个类嵌套，也能够被接口嵌套。这 在实际开发中可能应用的很少，但也是它的特性之一。须要注意的是，在实现某个接口时，并不须要实现嵌套在其内部的任何接口，并且，private接口不能 在定义它的类以外被实现。