Java_abstract class和interface的

via: http://blog.csdn.net/b271737818/article/details/3950245

 

在Java语言中，abstract class和interface是支持抽象类定义的两种机制。正是由于这两种机制的存在，才赋予了Java强大的面向对象能力。abstract class和interface之间在对于抽象类定义的支持方面具有很大的相似性，甚至可以相互替换，因此很多开发者在进行抽象类定义时对于abstract class和interface的选择显得比较随意。其实，两者之间还是有很大的区别的，对于它们的选择甚至反映出对于问题领域本质的理解、对于设计意图的理解是否正确、合理。

	Abstract class	Interface
实例化	不能	不能
类	一种继承关系，一个类只能使用一次继承关系。可以通过继承多个接口实现多重继承	一个类可以实现多个interface
数据成员	可有自己的	静态的不能被修改即必须是static final，一般不在此定义
方法	可以私有的，非abstract方法，必须实现	不可有私有的，默认是public，abstract 类型
变量	可有私有的，默认是friendly 型，其值可以在子类中重新定义，也可以重新赋值	不可有私有的，默认是public static final 型，且必须给其初值，实现类中不能重新定义，不能改变其值
设计理念	表示的是“is-a”关系	表示的是“like-a”关系
实现	需要继承，要用extends	要用implements

abstract class和interface在Java语言中都是用来进行抽象类（本文中的抽象类并非从abstract class翻译而来，它表示的是一个抽象体，而abstract class为Java语言中用于定义抽象类的一种方法）定义的，那么什么是抽象类，使用抽象类能为我们带来什么好处呢？

声明方法的存在而不去实现它的类被叫做抽象类（abstract class），它用于要创建一个体现某些基本行为的类，并为该类声明方法，但不能在该类中实现该类的情况。不能创建abstract 类的实例。然而可以创建一个变量，其类型是一个抽象类，并让它指向具体子类的一个实例。不能有抽象构造函数或抽象静态方法。Abstract 类的子类为它们父类中的所有抽象方法提供实现，否则它们也是抽象类为。取而代之，在子类中实现该方法。知道其行为的其它类可以在类中实现这些方法。

接口（interface）是抽象类的变体。在接口中，所有方法都是抽象的。多继承性可通过实现 这样的接口而获得。接口中的所有方法都是抽象的，没有一个有程序体。接口只可以定义static final成员变量。接口的实现与子类相似，除了该实现类不能从接口定义中继承行为。当类实现特殊接口时，它定义（即将程序体给予）所有这种接口的方法。 然后，它可以在实现了该接口的类的任何对象上调用接口的方法。由于有抽象类，它允许使用接口名作为引用变量的类型。通常的动态联编将生效。引用可以转换到 接口类型或从接口类型转换，instanceof 运算符可以用来决定某对象的类是否实现了接口。

接口可以继承接口。抽象类可以实现(implements)接口，抽象类是可以继承实体类，但前提是实体类必须有明确的构造函数。接口更关注“能实现什么功能”，而不管“怎么实现的”。

1.相同点
  A. 两者都是抽象类，都不能实例化。
  B. interface实现类及abstrct class的子类都必须要实现已经声明的抽象方法。

2. 不同点
  A. interface需要实现，要用implements，而abstract class需要继承，要用extends。
  B. 一个类可以实现多个interface，但一个类只能继承一个abstract class。
  C. interface强调特定功能的实现，而abstract class强调所属关系。 
  D. 尽管interface实现类及abstrct class的子类都必须要实现相应的抽象方法，但实现的形式不同。interface中的每一个方法都是抽象方法，都只是声明的 (declaration, 没有方法体)，实现类必须要实现。而abstract class的子类可以有选择地实现。
  这个选择有两点含义：
    一是Abastract class中并非所有的方法都是抽象的，只有那些冠有abstract的方法才是抽象的，子类必须实现。那些没有abstract的方法，在Abstrct class中必须定义方法体。
    二是abstract class的子类在继承它时，对非抽象方法既可以直接继承，也可以覆盖；而对抽象方法，可以选择实现，也可以通过再次声明其方法为抽象的方式，无需实现，留给其子类来实现，但此类必须也声明为抽象类。既是抽象类，当然也不能实例化。
  E. abstract class是interface与Class的中介。
  interface是完全抽象的，只能声明方法，而且只能声明pulic的方法，不能声明private及protected的方法，不能定义方法体，也 不能声明实例变量。然而，interface却可以声明常量变量，并且在JDK中不难找出这种例子。但将常量变量放在interface中违背了其作为接 口的作用而存在的宗旨，也混淆了interface与类的不同价值。如果的确需要，可以将其放在相应的abstract class或Class中。
  abstract class在interface及Class中起到了承上启下的作用。一方面，abstract class是抽象的，可以声明抽象方法，以规范子类必须实现的功能；另一方面，它又可以定义缺省的方法体，供子类直接使用或覆盖。另外，它还可以定义自己 的实例变量，以供子类通过继承来使用。

3. interface的应用场合
  A. 类与类之前需要特定的接口进行协调，而不在乎其如何实现。
  B. 作为能够实现特定功能的标识存在，也可以是什么接口方法都没有的纯粹标识。
  C. 需要将一组类视为单一的类，而调用者只通过接口来与这组类发生联系。
  D. 需要实现特定的多项功能，而这些功能之间可能完全没有任何联系。

4. abstract class的应用场合
  一句话，在既需要统一的接口，又需要实例变量或缺省的方法的情况下，就可以使用它。最常见的有：
  A. 定义了一组接口，但又不想强迫每个实现类都必须实现所有的接口。可以用abstract class定义一组方法体，甚至可以是空方法体，然后由子类选择自己所感兴趣的方法来覆盖。
  B. 某些场合下，只靠纯粹的接口不能满足类与类之间的协调，还必需类中表示状态的变量来区别不同的关系。abstract的中介作用可以很好地满足这一点。
  C. 规范了一组相互协调的方法，其中一些方法是共同的，与状态无关的，可以共享的，无需子类分别实现；而另一些方法却需要各个子类根据自己特定的状态来实现特定的功能。

 

via: http://www.ibm.com/developerworks/cn/java/l-javainterface-abstract/

从语法定义层面看abstract class和interface

在语法层面，Java语言对于abstract class和interface给出了不同的定义方式，下面以定义一个名为Demo的抽象类为例来说明这种不同。

使用abstract class的方式定义Demo抽象类的方式如下：

abstract class Demo ｛
	abstract void method1();
	abstract void method2();
	…
｝

使用interface的方式定义Demo抽象类的方式如下：

interface Demo {
	void method1();
	void method2();
	…
}

在abstract class方式中，Demo可以有自己的数据成员，也可以有非abstarct的成员方法，而在interface方式的实现中，Demo只能够有静态的不能被修改的数据成员（也就是必须是static final的，不过在interface中一般不定义数据成员），所有的成员方法都是abstract的。从某种意义上说，interface是一种特殊形式的abstract class。

从编程层面看abstract class和interface

从编程的角度来看，abstract class和interface都可以用来实现"design by contract"的思想。但是在具体的使用上面还是有一些区别的。

首先，abstract class在Java语言中表示的是一种继承关系，一个类只能使用一次继承关系。但是，一个类却可以实现多个interface。也许，这是Java语言的设计者在考虑Java对于多重继承的支持方面的一种折中考虑吧。

其次，在abstract class的定义中，我们可以赋予方法的默认行为。但是在interface的定义中，方法却不能拥有默认行为，为了绕过这个限制，必须使用委托，但是这会 增加一些复杂性，有时会造成很大的麻烦。

在抽象类中不能定义默认行为还存在另一个比较严重的问题，那就是可能会造成维护上的麻烦。因为如果后来想修改类的界面（一般通过abstract class或者interface来表示）以适应新的情况（比如，添加新的方法或者给已用的方法中添加新的参数）时，就会非常的麻烦，可能要花费很多的时间（对于派生类很多的情况，尤为如此）。但是如果界面是通过abstract class来实现的，那么可能就只需要修改定义在abstract class中的默认行为就可以了。

同样，如果不能在抽象类中定义默认行为，就会导致同样的方法实现出现在该抽象类的每一个派生类中，违反了"one rule，one place"原则，造成代码重复，同样不利于以后的维护。因此，在abstract class和interface间进行选择时要非常的小心。

 

从设计理念层面看abstract class和interface

上面主要从语法定义和编程的角度论述了abstract class和interface的区别，这些层面的区别是比较低层次的、非本质的。本小节将从另一个层面：abstract class和interface所反映出的设计理念，来分析一下二者的区别。作者认为，从这个层面进行分析才能理解二者概念的本质所在。

前面已经提到过，abstarct class在Java语言中体现了一种继承关系，要想使得继承关系合理，父类和派生类之间必须存在"is a"关系，即父类和派生类在概念本质上应该是相同的（参考文献〔3〕中有关于"is a"关系的大篇幅深入的论述，有兴趣的读者可以参考）。对于interface 来说则不然，并不要求interface的实现者和interface定义在概念本质上是一致的，仅仅是实现了interface定义的契约而已。为了使论述便于理解，下面将通过一个简单的实例进行说明。

考虑这样一个例子，假设在我们的问题领域中有一个关于Door的抽象概念，该Door具有执行两个动作open和close，此时我们可以通过abstract class或者interface来定义一个表示该抽象概念的类型，定义方式分别如下所示：

使用abstract class方式定义Door：

	abstract class Door {
		abstract void open();
		abstract void close()；
}

使用interface方式定义Door：

interface Door {
		void open();
	void close();
}

其他具体的Door类型可以extends使用abstract class方式定义的Door或者implements使用interface方式定义的Door。看起来好像使用abstract class和interface没有大的区别。

如果现在要求Door还要具有报警的功能。我们该如何设计针对该例子的类结构呢（在本例中，主要是为了展示abstract class和interface反映在设计理念上的区别，其他方面无关的问题都做了简化或者忽略）？下面将罗列出可能的解决方案，并从设计理念层面对这些不同的方案进行分析。

解决方案一：

简单的在Door的定义中增加一个alarm方法，如下：

	abstract class Door {
		abstract void open();
		abstract void close()；
		abstract void alarm();
}

或者

interface Door {
		void open();
	void close();
	void alarm();
}

那么具有报警功能的AlarmDoor的定义方式如下：

	class AlarmDoor extends Door {
		void open() { … }
    		void close() { … }
		void alarm() { … }
}

或者

	class AlarmDoor implements Door ｛
	void open() { … }
    		void close() { … }
		void alarm() { … }
｝

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

解决方案二：

既然open、close和alarm属于两个不同的概念，根据ISP原则应该把它们分别定义在代表这两个概念的抽象类中。定义方式有：这两个概念都使用abstract class方式定义；两个概念都使用interface方式定义；一个概念使用abstract class方式定义，另一个概念使用interface方式定义。

显然，由于Java语言不支持多重继承，所以两个概念都使用abstract class方式定义是不可行的。后面两种方式都是可行的，但是对于它们的选择却反映出对于问题领域中的概念本质的理解、对于设计意图的反映是否正确、合理。我们一一来分析、说明。

如果两个概念都使用interface方式来定义，那么就反映出两个问题：1、我们可能没有理解清楚问题领域，AlarmDoor在概念本质上到底是Door还是报警器？2、如果我们对于问题领域的理解没有问题，比如：我们通过对于问题领域的分析发现AlarmDoor在概念本质上和Door是一致的，那么我们在实现时就没有能够正确的揭示我们的设计意图，因为在这两个概念的定义上（均使用interface方式定义）反映不出上述含义。

如果我们对于问题领域的理解是：AlarmDoor在概念本质上是Door，同时它有具有报警的功能。我们该如何来设计、实现来明确的反映出我们的意思呢？前面已经说过，abstract class在Java语言中表示一种继承关系，而继承关系在本质上是"is a"关系。所以对于Door这个概念，我们应该使用abstarct class方式来定义。另外，AlarmDoor又具有报警功能，说明它又能够完成报警概念中定义的行为，所以报警概念可以通过interface方式定义。如下所示：

	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() { … }
}

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

 

-------------------------------

1．实现继承与接口继承

 

实现继承通常情况下表现为对抽象类的继承，而其与接口继承在规则上有以下几点归纳： 

— 抽象类适合于有族层概念的类间关系，而接口最适合为不同的类提供通用功能。 

— 接口着重于CAN-DO关系类型，而抽象类则偏重于IS-A式的关系。 

— 接口多定义对象的行为；抽象类多定义对象的属性。 

— 如果预计会出现版本问题，可以创建“抽象类”。例如，创建了狗（Dog）、鸡（Chicken）和鸭（Duck），那么应该考虑抽象出动物（Animal）来应对以后可能出现马和牛的事情。而向接口中添加新成员则会强制要求修改所有派生类，并重新编译，所以版本式的问题最好以抽象类来实现。 

— 因为值类型是密封的，所以只能实现接口，而不能继承类。

 

接口继承是出自设计模式中的一个概念。

接口继承，又称子类型化。描述了一个对象什么时候能够被用来替代另一个对象。

 

---------------------------------------------

via: http://ifeve.com/%E5%88%9D%E6%8E%A2%E8%AE%BE%E8%AE%A1%EF%BC%9Ajava%E6%8E%A5%E5%8F%A3%E5%92%8C%E6%8A%BD%E8%B1%A1%E7%B1%BB%E4%BD%95%E6%97%B6%E7%94%A8%EF%BC%9F%E6%80%8E%E4%B9%88%E7%94%A8%EF%BC%9F/#more-22677

一、接口和抽象类

类，即一个对象。

先抽象类，就是抽象出类的基础部分，即抽象基类（抽象类）。官方定义让人费解，但是记忆方法是也不错的 — 包含抽象方法的类叫做抽象类。

接口就是把抽象的深度更深，它就像用简短的非逻辑的一些规则表示类之间的关系。可以比作协议，比如通信使用的UDP/TCP协议等。

小结：类与接口是Java语言的基本抽象单元。

二、为什么有接口的两大原因

a. 向上转型为多个基类型

如此，会给开发带来相当大的灵活性。比如女神刘亦菲（Class），实现了 明星 和 女人 的接口。这样在复杂的继承结构的某类中使用它，以后在调用seeStar(Star star)或者seeWomen(Women women)方法时，只要传入其实现类（刘亦菲）即可。这也就是常说的接口可以多实现，达到了完全解耦。

b. 可复用性

即根据接口定义，让创建类有了遵循的”协议“（规则）。whatever~ 要做的仅仅建立一个接口，为了保证生成对象的非耦合。如此而来，接口的使用让代码更具可复用性，通用性和灵活性。但并不是那么万能。后面使用守则会讲到。

 

三、怎么用？

前人大牛总结了一些设计模式，也就是接口衍生出的一些设计模式。设计模式就是语法糖的甜蜜吧。接口让我们尝到了甜蜜。和我身边的一杯starBucks的热巧克力一样。有点太甜。比如：

a.策略模式 — 方法中参数使用接口，传入的参数对象（实现类）即包含了执行的代码。如图：

调用过程如下，在方法中出入实现而已：

 

b. 适配器模式 — 接口适配器（Interface Adapter）类，可以将不同源配到同一个目标。即暴露目标接口和实现源有共同的方法，适配器类怎么适配呢？实现目标接口，并关联了实现源对象，在实现方法中调用关联实现源真正对象，然后在里面进行各种适配操作。比如再关联一个源什么的。如图：

这其实有点AOP的味道。比如Spring AOP框架对BeforeAdvice、AfterAdvice、ThrowsAdvice三种通知类型的支持实际上是借助适配器模式来实现的。

 

c. 工厂模式 — 工厂对象将生成接口某个实现的对象。从而代码将实现和接口的实现分离，比较透明地将某个实现透明地替换成另一个实现。但是这里工厂调用方法是静态的，也就是简单工厂模式（静态工厂模式）。动态工厂模式无非是使用了反射达到了动态调用。

 

四、接口与抽象类的使用守则

第一、尽可能使每一个类或成员不被外界访问

这里的外界有个度，比如包级或者公有的。这样子可以更好地模块化，模块与模块之间通过暴露的api调动。这样如果有个模块改动接口或者类。只要担心该模块，而不会涉及其他模块。

第二、适当的使用类（抽象类）继承，更多的使用复合

继承，实现了代码重用。内部中使用继承非常安全，但是要记住什么时候使用继承。即当子类真正是超类的子类型时，才适用继承。否则尽可能使用复合，即在一个类中引用另一个类的实例。也就是说将另一个类包装了一下，这也就是装饰模式所体现的。

第三、优先考虑使用接口，相比抽象类

首先Java只许单继承，这导致抽象类定义收到极大的限制。二者，接口无法实现方法。但是Java 8提供了函数式接口。

但是接口在设计的时候注意，设计公有接口必须谨慎。接口如果被公开发行，则肯定会被广泛实现，那样改接口几乎不可能，会是巨大的工程。（这和我犯的错误一样。）