抽象类与接口

怼烎@ 2022-08-23 04:54 288阅读 0赞

一个软件设计的好坏，很大程度上取决于它的整体架构，而这个整体架构其实就是整个宏观商业业务的抽象框架，当代表业务逻辑的高层抽象层结构合理时，底层的具体实现需要考虑的就仅仅是一些算法和一些具体的业务实现了。当你需要再开发另一个相近的项目时，你以前的抽象层说不定还可以再次利用。面向对象的设计，复用的重点其实应该是抽象层的复用，而不是具体某一个代码块的复用。

既然面向对象设计的重点在于抽象，那Java接口和Java抽象类就有它存在的必然性了。正是由于他们的存在才赋予java强大的面向对象的能力。他们两者之间对抽象概念的支持有很大的相似，甚至可以互换，但是也有区别。

Java接口(interface)和Java抽象类(abstract class)代表的就是抽象类型，就是我们需要提出的抽象层的具体表现。OOP面向对象的编程，如果要提高程序的复用率，增加程序 的可维护性，可扩展性，就必须是面向接口的编程，面向抽象的编程，正确地使用接口、抽象类这些有用的抽象类型作为你结构层次上的顶层。

# 一、抽象类 #

我们都知道在面向对象的领域一切都是对象，同时所有的对象都是通过类来描述的，但是并不是所有的类都是来描述对象的。如果一个类没有足够的信息来描述一个具体的对象，而需要其他具体的类来支撑它，那么这样的类我们称它为抽象类。比如new Animal()，我们都知道这个是产生一个动物Animal对象，但是这个Animal具体长成什么样子我们并不知道，它没有一个具体动物的概念，所以他就是一个抽象类，需要一个具体的动物，如狗、猫来对它进行特定的描述，我们才知道它长成啥样。

在面向对象领域由于抽象的概念在问题领域没有对应的具体概念，所以用以表征抽象概念的抽象类是不能实例化的。同时，抽象类体现了数据抽象的思想，是实现多态的一种机制。它定义了一组抽象的方法，至于这组抽象方法的具体表现形式有派生类来实现。

**抽象类通常代表一个抽象概念，他提供一个继承的出发点，当设计一个新的抽象类时，一定是用来继承的。所以，在一个以继承关系形成的等级结构里面，树叶节点应当是具体类，而树枝节点均应当是抽象类。**

![Center][]

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

1、抽象类不能被实例化（像刚才的动物，实例化是没有任何意义的），实例化的工作应该交由它的子类来完成，它只需要有一个引用即可。

2、抽象方法必须由子类来进行重写。

3、如果类中包含抽象方法，该类必须要定义成抽象类，不管是否还包含有其他方法。

4、抽象类中可以包含具体的方法，当然也可以不包含抽象方法。

5、子类中的抽象方法不能与父类的抽象方法同名。

6、abstract不能与final并列修饰同一个类。

7、abstract 不能与private、static、final或native并列修饰同一个方法。

创建抽象类和抽象方法非常有用,因为他们可以使类的抽象性明确起来,并告诉用户和编译器打算怎样使用他们.抽象类还是有用的重构器,因为它们使我们可以很容易地将公共方法沿着继承层次结构向上移动。

**实例：**

定义一个抽象动物类Animal，提供抽象方法叫cry()，猫、狗都是动物类的子类，由于cry()为抽象方法，所以Cat、Dog必须要实现cry()方法。如下：

1. **public abstract class** Animal \{

2.     **public abstract void** cry();

3. \}

5. **public class** Cat **extends** Animal\{

7.     @Override

8.     **public void** cry() \{

9.         System.out.println("猫叫：喵喵...");

10.     \}

11. \}

12.

13. **public class** Dog **extends** Animal\{

14.

15.     @Override

16.     **public void** cry() \{

17.         System.out.println("狗叫:汪汪...");

18.     \}

19.

20. \}

21.

22. **public class** Test \{

23.

24.     **public static void** main(String\[\] args) \{

25.         Animal a1 = **new** Cat();

26.         Animal a2 = **new** Dog();

27.

28.         a1.cry();

29.         a2.cry();

30.     \}

31. \}

32.

33. --------------------------------------------------------------------

34. Output:

35. 猫叫：喵喵...

36. 狗叫:汪汪...

# **二、接口** #

接口是一种比抽象类更加抽象的“类”。这里给“类”加引号是我找不到更好的词来表示，但是我们要明确一点就是，接口本身就不是类，从我们不能实例化一个接口就可以看出。如new Runnable();肯定是错误的，我们只能new它的实现类。

**接口是用来建立类与类之间的协议，它所提供的只是一种形式，而没有具体的实现。同时实现该接口的实现类必须要实现该接口的所有方法**，通过使用implements关键字，他表示该类在遵循某个或某组特定的接口，同时也表示着“interface只是它的外貌，但是现在需要声明它是如何工作的”。

接口是抽象类的延伸，java了保证数据安全是不能多重继承的，**也就是说继承只能存在一个父类，但是接口不同，一个类可以同时实现多个接口，不管这些接口之间有没有关系，**所以接口弥补了抽象类不能多重继承的缺陷，但是推荐继承和接口共同使用，因为这样既可以保证数据安全性又可以实现多重继承。

在使用接口过程中需要注意如下几个问题：

1.  Interface的所有方法访问权限自动被声明为public。
2.  接口中的“成员变量”会自动变为public static final（不可变的常量）类型。可以通过类命名直接访问：ImplementClass.name。
3.  接口中不存在实现的方法。
4.  实现接口的非抽象类必须要实现该接口的所有方法。抽象类可以不用实现。
5.  不能使用new操作符实例化一个接口，但可以声明一个接口变量，该变量必须引用（refer to)一个实现该接口的类的对象。可以使用 instanceof 检查一个对象是否实现了某个特定的接口。例如：if(anObject instanceof Comparable)\{\}。
6.  在实现多接口的时候一定要避免方法名的重复。
7.  一个类可以支持多个接口，多个类也可以支持相同的接口

# 三、抽象类与接口的区别 #

## **3.1语法层次** ##

### **3.1.1 Java接口和Java抽象类最大的一个区别，就在于Java抽象类可以提供某些方法的部分实现，而Java接口不可以** ###

就是interface中只能定义方法，而不能有方法的实现，而在abstract class中则可以既有方法的具体实现，又有没有具体实现的抽象方法，这大概就是Java抽象类唯一的优点吧，但这个优点非常有用。如果向一个抽象类里加入一个新的具体方法时，那么它所有的子类都一下子都得到了这个新方法，而Java接口做不到这一点，如果向一个Java接口里加入一个新方法，所有实现这个接口的类就无法成功通过编译了，因为你必须让每一个类都再实现这个方法才行，这显然是Java接口的缺点。

### **3.1.2 一个抽象类的实现只能由这个抽象类的子类给出** ###

**    **也就是说，这个实现处在抽象类所定义出的继承的等级结构中，而由于Java语言的单继承性，所以抽象类作为类型定义工具的效能大打折扣。在这一点上，Java接口的优势就出来了，**任何一个实现了一个Java接口所规定的方法的类都可以具有这个接口的类型，而一个类可以实现任意多个Java接口，从而这个类就有了多种类型。**（使用抽象类，那么继承这个抽象类的子类类型就比较单一，因为子类只能单继承抽象类；而子类能够同时实现多个接口，因为类型就比较多。接口和抽象类都可以定义对象，但是只能用他们的具体实现类来进行实例化。）

### **3.1.3 对子类而言，它只能继承一个抽象类（这是java为了数据安全而考虑的），但是却可以实现多个接口。**   ** ** ###

## **3.2 设计层次** ##

### **3.2.1 抽象层次不同。** ###

抽象类是对类抽象，而接口是对行为的抽象。抽象类是对整个类整体进行抽象，包括属性、行为，但是接口却是对类局部（行为）进行抽象。

### **3.2.2 跨域不同。** ###

抽象类所跨域的是具有相似特点的类，而接口却可以跨域不同的类。我们知道抽象类是从子类中发现公共部分，然后泛化成抽象类，子类继承该父类即可，但是接口不同。实现它的子类可以不存在任何关系，共同之处。例如猫、狗可以抽象成一个动物类抽象类，具备叫的方法。鸟、飞机可以实现飞Fly接口，具备飞的行为，这里我们总不能将鸟、飞机共用一个父类吧！所以说**抽象类所体现的是一种继承关系**，要想使得继承关系合理，父类和派生类之间必须存在**"[is][]\-a" 关系**，即父类和派生类在概念本质上应该是相同的。对于**接口**则不然，**并不要求接口的实现者和接口定义在概念本质上是一致的，仅仅是实现了接口定义的契约而已**。

### **3.2.3 设计层次不同。** ###

对于抽象类而言，它是自下而上来设计的，我们要先知道子类才能抽象出父类，而接口则不同，它根本就不需要知道子类的存在，只需要定义一个规则即可，至于什么子类、什么时候怎么实现它一概不知。比如我们只有一个猫类在这里，如果你这是就抽象成一个动物类，是不是设计有点儿过度？我们起码要有两个动物类，猫、狗在这里，我们在抽象他们的共同点形成动物抽象类吧！所以说抽象类往往都是通过重构而来的！但是接口就不同，比如说飞，我们根本就不知道会有什么东西来实现这个飞接口，怎么实现也不得而知，我们要做的就是事前定义好飞的行为接口。**所以说抽象类是自底向上抽象而来的，接口是自顶向下设计出来的。**

# 四、实例分析 #

下面将使用一个例子来说明。该例子引自：[http://blog.csdn.net/ttgjz/article/details/2960451][http_blog.csdn.net_ttgjz_article_details_2960451]

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

抽象类：

**\[java\]** [view plain][] [copy][view plain]

[print][view plain][?][view plain][![在CODE上查看代码片][CODE]][CODE_CODE][![派生到我的代码片][ico_fork.svg]][ico_fork.svg 1]

1.  **abstract** **class** Door\{  
2.      **abstract** **void** open();  
3.      **abstract** **void** close()；  
4.  \}

接口：

**\[java\]** [view plain][] [copy][view plain]

[print][view plain][?][view plain][![在CODE上查看代码片][CODE]][CODE_CODE][![派生到我的代码片][ico_fork.svg]][ico_fork.svg 1]

1.  **interface** Door\{  
2.      **void** open();  
3.      **void** close();  
4.  \}

至于其他的具体类可以通过使用extends使用抽象类方式定义Door或者Implements使用接口方式定义Door，这里发现两者并没有什么很大的差异。

但是现在如果我们需要门具有报警的功能，那么该如何实现呢？

## **    解决方案一**： ##

给Door增加一个报警方法:clarm();

**\[java\]** [view plain][] [copy][view plain]

[print][view plain][?][view plain][![在CODE上查看代码片][CODE]][CODE_CODE][![派生到我的代码片][ico_fork.svg]][ico_fork.svg 1]

1.  **abstract** **class** Door\{  
2.      **abstract** **void** open();  
3.      **abstract** **void** close();  
4.      **abstract** **void** alarm();  
5.  \}

或者：

**\[java\]** [view plain][] [copy][view plain]

[print][view plain][?][view plain][![在CODE上查看代码片][CODE]][CODE_CODE][![派生到我的代码片][ico_fork.svg]][ico_fork.svg 1]

1.  **interface** Door\{  
2.      **void** open();  
3.      **void** close();  
4.      **void** alarm();  
5.  \}

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

## **    解决方案二：** ##

既然open()、close()和alarm()属于两个不同的概念，那么我们依据ISP原则将它们分开定义在两个代表两个不同概念的抽象类里面，定义的方式有三种：

1、两个都使用抽象类来定义。

2、两个都使用接口来定义。

3、一个使用抽象类定义，一个是用接口定义。

由于java不支持多继承所以第一种是不可行的。后面两种都是可行的，但是选择何种就反映了你对问题域本质的理解。

如果选择第二种都是接口来定义，那么就反映了两个问题：

1、我们可能没有理解清楚问题域，AlarmDoor在概念本质上到底是门还报警器。

2、如果我们对问题域的理解没有问题，比如我们在分析时确定了AlarmDoor在本质上概念是一致的，那么我们在设计时就没有正确的反映出我们的设计意图。因为你使用了两个接口来进行定义，他们概念的定义并不能够反映上述含义。

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

**\[java\]** [view plain][] [copy][view plain]

[print][view plain][?][view plain][![在CODE上查看代码片][CODE]][CODE_CODE][![派生到我的代码片][ico_fork.svg]][ico_fork.svg 1]

1.  **abstract** **class** Door\{  
2.      **abstract** **void** open();  
3.      **abstract** **void** close();  
4.  \}  
5.    
6.  **interface** Alarm\{  
7.      **void** alarm();  
8.  \}  
9.    
10. **class** AlarmDoor **extends** Door **implements** Alarm\{  
11.     **void** open()\{\}  
12.     **void** close()\{\}  
13.     **void** alarm()\{\}  
14. \}

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

<table style="font-family:'microsoft yahei'; font-size:15px; color:rgb(85,85,85); line-height:35px"> 
 <tbody> 
 <tr> 
 <td> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;批注： 
 <blockquote> 
 &nbsp;ISP（Interface Segregation Principle）：面向对象的一个核心原则。它表明使用多个专门的接口比使用单一的总接口要好。 
 &nbsp;一个类对另外一个类的依赖性应当是建立在最小的接口上的。 
 一个接口代表一个角色，不应当将不同的角色都交给一个接口。没有关系的接口合并在一起，形成一个臃肿的大接口，这是对角色和接口的污染。 
 </blockquote> </td> 
 </tr> 
 </tbody> 
</table>

#  #

# 五、总结 #

1、抽象类在java语言中所表示的是一种继承关系，一个子类只能存在一个父类，但是可以存在多个接口。

2、在抽象类中可以拥有自己的成员变量和非抽象类方法，但是接口中只能存在静态的不可变的成员数据（不过一般都不在接口中定义成员数据），而且它的所有方法都是抽象的。

3、抽象类和接口所反映的设计理念是不同的，抽象类所代表的是“is-a”的关系，而接口所代表的是“like-a”的关系。

抽象类和接口是java语言中两种不同的抽象概念，他们的存在对多态提供了非常好的支持，虽然他们之间存在很大的相似性。但是对于他们的选择往往反应了您对问题域的理解。只有对问题域的本质有良好的理解，才能做出正确、合理的设计。

[Center]: /images/20220721/afc7a6939cd64ddc8db4d1ff70f96b13.png
[is]: http://www.mydown.com/soft/network/chat/475/444475.shtml
[http_blog.csdn.net_ttgjz_article_details_2960451]: http://blog.csdn.net/ttgjz/article/details/2960451
[view plain]: http://blog.csdn.net/chenssy/article/details/12858267#
[CODE]: https://code.csdn.net/assets/CODE_ico.png
[CODE_CODE]: https://code.csdn.net/snippets/129610
[ico_fork.svg]: https://code.csdn.net/assets/ico_fork.svg
[ico_fork.svg 1]: https://code.csdn.net/snippets/129610/fork