抽象类和接口

抽象类和接口时Java语言中对抽象概念进行定义的两种机制，正是由于他们的存在才赋予Java强大的面向对象能力。

抽象类

在面向对象的领域Everything is Object，同时所有的对象都是通过类描述的，但是并不是所有的类都是来描述对象。如果一个类没有足够的信息来描述一个具体的对象，而需要其他具体的类来支撑它，那么这样的类我们称它为抽象类。抽象类体现了数据抽象的思想，是实现多态的一种机制。同时抽象类提供了继承的概念，它的出发点就是为了继承，否则它没有任何存在的意义。

在使用抽象类时需要注意几点：

抽象类不能被实例化，实例化的工作应该交由它的子类来完成，它只需要有一个引用即可。
抽象方法必须由子类来进行重写。
只要包含一个抽象方法的抽象类，该类必须要定义成抽象类，不管是否还包含有其他方法。
抽象类中可以包含具体的方法，当然也可以不包含抽象方法。
子类中的抽象方法不能与父类的抽象方法同名。
abstract不能与final并列修饰同一个类。
abstract 不能与private、static、final或native并列修饰同一个方法。

接口

接口是一种比抽象类更加抽象的“类”。这里给“类”加引号是我找不到更好的词来表示，因为接口本身就不是类。接口是用来建立类与类之间的协议，它提供的只是一种形式，而没有具体的实现。同时实现该接口的实现类必须实现该接口的所有方法，通过implements关键字，它表示该类在遵循某个或某组特定的接口。接口时抽象类的延伸，Java是不能多重继承的，而接口弥补了抽象类不能多重继承的缺陷。
在使用接口过程中需要注意如下几个问题：

Interface的所有方法访问权限自动被声明为public。确切的说只能为public，当然你可以显示的声明为protected、private，但是编译会出错！
接口中可以定义“成员变量”，或者说是不可变的常量，因为接口中的“成员变量”会自动变为为public static final。可以通过类命名直接访问：ImplementClass.name。
接口中不存在实现的方法
不能使用new操作符实例化一个接口，但可以声明一个接口变量，该变量必须引用（refer to)一个实现该接口的类的对象。

抽象类与接口的区别

语法层次上，抽象类可以拥有任意范围的成员数据，同时也可以拥有自己的非抽象方法，但是接口中，它仅能够有静态，不能修改的成员数据，同时它所有方法必须是抽象的。

设计层次上：
1、抽象层次不同。抽象类是对整个类整体进行抽象，包括属性、行为，但是接口却是对类局部（行为）进行抽象。
2、跨域不同。抽象类所跨域的是具有相似特点的类，而接口却可以跨域不同的类。我们知道抽象类是从子类中发现公共部分，然后泛化成抽象类，子类继承该父类即可，但是接口不同。实现它的子类可以不存在任何关系，共同之处。例如猫、狗可以抽象成一个动物类抽象类，具备叫的方法。鸟、飞机可以实现飞Fly接口，具备飞的行为，这里我们总不能将鸟、飞机共用一个父类吧！所以说抽象类所体现的是一种继承关系。对于接口则不然，并不要求接口的实现和接口定义在概念本质上是一致的，仅仅是实现了接口定义的契约而已。
3、设计层次不同。对于抽象类而言，它是自下而上来设计的，我们要先知道子类才能抽象出父类，而接口则不同，它根本就不需要知道子类的存在，只需要定义一个规则即可，至于什么子类、什么时候怎么实现它一概不知。

案例分析：有一个Door的抽象概念，它具备两个行为open()和close()，此时我们可以定义通过抽象类和接口来定义这个抽象概念：

      abstract  class Door{
      public void close();
      public void open();
      }
或者
      interface Door{
      void open();
      void close();
      }

但是现在如果我们需要门具有报警的功能，那么该如何实现呢？？？
解决方案一：给Door增加一个报警方法:clarm()

 abstract  class Door{
      public void close();
      public void open();
      public void alarm();
      }
或者
      interface Door{
      void open();
      void close();
      void alarm();
      }

这种方法违反了面向对象设计中的一个核心原则 ISP (Interface Segregation Principle),在Door的定义中把Door概念本身固有的行为方法和另外一个概念”报警器”的行为方法混在了一起。这样引起的一个问题是那些仅仅依赖于Door这个概念的模块会因为”报警器”这个概念的改变而改变，反之依然。

解决方案二
既然open()、close()和alarm()属于两个不同的概念，那么我们依据ISP原则将它们分开定义在两个代表两个不同概念的抽象类里面，定义的方式有三种：
1、两个都使用抽象类来定义。
2、两个都使用接口来定义。
3、一个使用抽象类定义，一个是用接口定义。
由于java不支持多继承所以第一种是不可行的。后面两种都是可行的，但是选择何种就反映了你对问题域本质的理解。如果选择第二种都是接口来定义，那么就反映了两个问题：1、我们可能没有理解清楚问题域，AlarmDoor在概念本质上到底是门还报警器。

第三种，如果我们对问题域的理解是这样的：AlarmDoor本质上Door，但同时它也拥有报警的行为功能，这个时候我们使用第三种方案恰好可以阐述我们的设计意图。AlarmDoor本质是门，所以对于这个概念我们使用抽象类来定义，同时AlarmDoor具备报警功能，说明它能够完成报警概念中定义的行为功能，所以alarm可以使用接口来进行定义。如下：

 abstract class Door{  
    abstract void open();  
    abstract void close();  
}  
  
interface Alarm{  
    void alarm();  
}  
  
class AlarmDoor extends Door implements Alarm{  
    void open(){}  
    void close(){}  
    void alarm(){}  
}

这种实现方式基本上能够明确的反映出我们对于问题领域的理解，正确的揭示我们的设计意图。其实抽象类表示的是”is-a”关系，接口表示的是”like-a”关系，大家在选择时可以作为一个依据，当然这是建立在对问题领域的理解上的，比如：如果我们认为AlarmDoor在概念本质上是报警器，同时又具有Door的功能，那么上述的定义方式就要反过来了。