Java 中的接口和抽象类的区别

Dear 丶 2024-04-06 12:22 68阅读 0赞

**目录**

1、扩展知识

2、面向对象设计

3、OOP 原则(开闭原则)在实践代码中的分析

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

接口和抽象类是 Java 面向对象设计的两个基础机制。

**接口**是对行为的抽象，它是抽象方法的集合，利用接口可以达到 **API 定义和实现分离**的目的。接口，不能实例化；不能包含任何非常量成员，任何 field 都是隐含着 public static final 的意义；同时，没有非静态方法实现，也就是说要么是抽象方法，要么是静态方法。Java 标准类库中，定义了非常多的接口，比如 java.util.List。

**抽象类**是不能实例化的类，用 abstract 关键字修饰 class，其目的主要是**代码重用**。除了不能实例化，形式上和一般的 Java 类并没有太大区别，可以有一个或者多个抽象方法，也可以没有抽象方法。抽象类大多用于抽取相关 Java 类的共用方法实现或者是共同成员变量，然后通过继承的方式达到代码复用的目的。Java 标准库中，比如 collection 框架，很多通用部分就被抽取成为抽象类，例如 java.util.AbstractList。

Java 类实现 interface 使用 implements 关键词，继承 abstract class 则是使用 extends 关键词，我们可以参考 Java 标准库中的 ArrayList。

#### 1、扩展知识 ####

Java 相比于其他面向对象语言，如 C++，设计上有一些基本区别，比如 **Java 不支持多继承**。这种限制，在规范了代码实现的同时，也产生了一些局限性，影响着程序设计结构。Java 类可以实现多个接口，因为接口是抽象方法的集合，所以这是声明性的，但不能通过扩展多个抽象类来重用逻辑。// Java 不支持多继承，接口是抽象方法的集合

在一些情况下存在特定场景，需要抽象出与具体实现、实例化无关的通用逻辑，或者纯调用关系的逻辑，但是使用传统的抽象类会陷入到单继承的窘境。以往常见的做法是，实现由静态方法组成的工具类（Utils），比如 java.util.Collections。// 通用逻辑可以定义静态方法组成的工具类

设想，为接口添加任何抽象方法，相应的所有实现了这个接口的类，也必须实现新增方法，否则会出现编译错误。对于抽象类，如果我们添加非抽象方法，其子类只会享受到能力扩展，而不用担心编译出问题。// 抽象类中可以添加非抽象方法

接口的职责也不仅仅限于抽象方法的集合，其实有各种不同的实践。有一类没有任何方法的接口，通常叫作 Marker Interface，顾名思义，它的目的就是为了声明某些东西，比如我们熟知的 Cloneable、Serializable 等。这种用法，也存在于业界其他的 Java 产品代码中。

从表面看，这似乎和 Annotation 异曲同工，也确实如此，它的好处是简单直接。对于 Annotation，因为可以指定参数和值，在表达能力上要更强大一些，所以更多人选择使用 Annotation。// 接口和注解都可以声明某些东西，但是注解可以指定参数和值，试想，注解是不是就是借鉴了Marker Interface 的想法？

Java 8 增加了函数式编程的支持，所以又增加了一类定义，即所谓 functional interface，简单说就是只有一个抽象方法的接口，通常建议使用 @FunctionalInterface Annotation 来标记。Lambda 表达式本身可以看作是一类 functional interface，某种程度上这和面向对象可以算是两码事。我们熟知的 Runnable、Callable 之类，都是 functional interface，这里不再多介绍了，有兴趣你可以参考：https://www.oreilly.com/learning/java-8-functional-interfaces 。

还有一点可能让人感到意外，严格说，**Java 8 以后，接口也是可以有方法实现的！**//default method

从 Java 8 开始，interface 增加了对 default method 的支持。Java 9 以后，甚至可以定义 private default method。Default method 提供了一种二进制兼容的扩展已有接口的办法。比如，我们熟知的 java.util.Collection，它是 collection 体系的 root interface，在 Java 8 中添加了一系列 default method，主要是增加 Lambda、Stream 相关的功能。类似 Collections 之类的工具类，很多方法都适合作为 default method 实现在基础接口里面。你可以参考下面代码片段：

// Default method 以兼容方式扩展已有接口

public interface Collection<E> extends Iterable<E> {
         /**
         * Returns a sequential Stream with this collection as its source 
         * ...
         **/
         default Stream<E> stream() { // 可以有具体的方法实现
             return StreamSupport.stream(spliterator(), false);
         }
      }

#### 2、面向对象设计 ####

我们一定要清楚面向对象的基本要素：封装、继承、多态。

**封装**的目的是隐藏事务内部的实现细节，以便提高安全性和简化编程。封装提供了合理的边界，避免外部调用者接触到内部的细节。我们在日常开发中，因为无意间暴露了细节导致的难缠 bug 太多了，比如在多线程环境暴露内部状态，导致的并发修改问题。从另外一个角度看，封装这种隐藏，也提供了简化的界面，避免太多无意义的细节浪费调用者的精力。

**继承**是代码复用的基础机制，类似于我们对于马、白马、黑马的归纳总结。但要注意，继承可以看作是非常紧耦合的一种关系，父类代码修改，子类行为也会变动。在实践中，过度滥用继承，可能会起到反效果。

**多态**，你可能立即会想到重写（override）和重载（overload）、向上转型。简单说，重写是父子类中相同名字和参数的方法，不同的实现；重载则是相同名字的方法，但是不同的参数，本质上这些方法签名是不一样的，为了更好说明，请参考下面的样例代码：

// 重写同名同参数，重载同名不同参数

public int doSomething() {
        return 0;
    }
    // 方法重载：输入参数不同，意味着方法签名不同
    public int doSomething(List<String> strs) {
        return 0;
    }
    // 方法重写：不同实现，返回 1 而不是 0
    public int doSomething() {
        return 1;
    }

#### 3、OOP 原则(开闭原则)在实践代码中的分析 ####

// 本例完全是扩展知识的补充

看看下面这段代码，改编自某伟大公司产品代码，你觉得可以利用面向对象设计原则如何改进？

public class VIPCenter {
      void serviceVIP(T extend User user>) {
         if (user instanceof SlumDogVIP) { // VIP分类一
            // do somthing
          } else if(user instanceof RealVIP) { // VIP分类二
            // do somthing
          }
          // ...
      }
    }

这段代码的一个问题是，业务逻辑集中在一起，当出现新的用户类型时，比如，大数据发现了我们是肥羊，需要去收获一下， 这就需要直接去修改服务方法代码实现，这可能会意外影响不相关的某个用户类型逻辑。

利用开关原则，我们可以尝试改造为下面的代码：

public class VIPCenter {
       private Map<User.TYPE, ServiceProvider> providers;
       void serviceVIP(T extend User user） { // 根据具体用户类型调用
          providers.get(user.getType()).service(user);
       }
     }
    
    // service 方法接口抽象
    interface ServiceProvider{
       void service(T extend User user) ;
     }
    // 具体实现一
    class SlumDogVIPServiceProvider implements ServiceProvider{
       void service(T extend User user){
         // do somthing
       }
     }
    // 具体实现二
    class RealVIPServiceProvider implements ServiceProvider{
       void service(T extend User user) {
         // do something
       }
     }

上面的示例，将不同对象分类的服务方法进行抽象，把业务逻辑的紧耦合关系拆开，实现代码的隔离保证了方便的扩展。