此次，完全弄懂接口及抽象类

做者：伯特
出处：github.com/ruicbAndroid/LoulanPlan
声明：本文出自伯特的《 楼兰计划》，转载务必注明做者及出处。

本文旨在讨论抽象类和接口的做用、实例及使用场景，都是个人理解和总结。更多关于接口和抽象类的概念知识，可自行查阅相关文档。

1. 抽象类及其做用

抽象类，顾名思义，即类的抽象。

在介绍面向对象概念时，咱们知道类是客观事物的抽象，而抽象类又是类的进一步抽象，该怎么理解呢？

举个例子，咱们定义若干个类 class BMW、class Benz、class Audi，分别对客观事物“宝马”、“奔驰”、“奥迪”三种汽车进行抽象，包含相关属性和行为（即方法）。可是咱们知道，汽车都有通用的属性和行为，好比品牌、发动机、方向盘、轮胎等属性，前进、后退、转弯等行为，因此咱们能够在宝马、奔驰等汽车之上，进一步抽象出“汽车”类 abstract class Car，包含通用的特性（属性和方法）。让 BMW、Benz、Audi 等继承抽象类 extends Car，便拥有了汽车的通用特性，而后在抽象类基础上定义各自的特殊属性及方法。

这里的 abstract class Car 即抽象类，能够看出，抽象类是用来捕捉子类的通用特性的，包括属性及行为。

2. 接口及其做用

下面咱们来看看接口，假使我研发出来一台会飞的汽车“伯特莱斯”（Bote-Royce），在程序中定义以下：

class BoteRoyce extends Car {
    //...省略通用特性

    /**
     * 能够飞
     */
    void fly() {
        System.out.println("伪装会飞~");
    }
}

看起来没问题：

• BoteRoyce extends Car：表达这是一辆汽车；
• fly() 方法：体现这车能够飞。

可是，随着技术发展，出现了众多能够制造飞行汽车的厂商，难道每个能够飞的汽车都去定义一个 fly() 方法？

心想这还不简单，在抽象类 Car 中定义一个抽象方法 abstract void fly() 让子类去实现，不就能够了吗？

No No No... 正如不是全部牛奶都叫特仑苏同样，不是全部汽车都会飞，飞行功能不是汽车的通用特性。将 fly() 方法定义在 Car 中，显然违背了“抽象类用来捕捉子类的通用特性”这一原则。

在这种场景下，解决方案之一就是使用接口，以下：

/**
 * 飞行器接口
 */
public interface Aircraft {
    //定义抽象方法
    void fly();
}

类 BoteRoyce 的定义修改以下：

/*
 * 实现 Aircraft 接口，表示具有飞行器能力
 */
class BoteRoyce extends Car implements Aircraft {

    /**
     * 覆写接口方法，实现飞行能力
     */
    @Override
    void fly() {
        System.out.println("伪装会飞~");
    }
}

再有其余品牌的飞行汽车，均可以经过 extends Car implements Aircraft 实现飞行能力。

上述定义的 interface Aircraft 即为接口，咱们一般使用接口对行为进行抽象。

3. 接口和抽象类的区别

关于两者的区别，能够结合前面的例子，来加深理解。

抽象类是对类本质的抽象，表达的是 is a 的关系，好比：BMW is a Car。抽象类包含并实现子类的通用特性，将子类存在差别化的特性进行抽象，交由子类去实现。

而接口是对行为的抽象，表达的是 like a 的关系。好比：Bote-Royce like a Aircraft（像飞行器同样能够飞），但其本质上 is a Car。接口的核心是定义行为，即实现类能够作什么，至于实现类主体是谁、是如何实现的，接口并不关心。

4. 接口与抽象类的使用场景

熟悉 Java 的同窗可能会质疑，上述关于接口的使用，彻底能够经过再次抽象 Car 去实现：

/**
 * 会飞的汽车
 */
abstract class FlyCar extends Car {

    //定义抽象方法
    public abstract void fly();
}

普通的汽车依然 extends Car，能够飞行的汽车 extends FlyCar 便可：

/*
 * 继承 FlyCar，表示是能够飞行的汽车
 */
class BoteRoyce extends FlyCar {

    /**
     * 覆写抽象方法，实现飞行能力
     */
    @Override
    public void fly() {
        System.out.println("伪装会飞~");
    }
}

若是你也这么想，表示你 get 到了抽象类的点。不过话说回来，这样的话接口岂不是没有存在的意义了？

固然不是了。就 BoteRoyce 而言，若是你关心的是“飞行汽车”这个总体，那么定义抽象类 FlyCar 是个不错的选择；若是你关心的是汽车具有“飞行”的行为，那不妨继续沿用前面使用 Aircraft 接口的方案。

这一点与设计模式中六大原则之一的“里氏替换原则”不谋而合，该原则指出：全部引用基类（抽象类或接口）的地方必须能透明地使用其子类的对象。也就是说，当你遵循该原则时，你必需要考虑你关心的是“飞行汽车”实体，仍是“飞行”行为，并将其做为基类，从而决定程序所能接受的子类对象。

同时，“接口隔离原则”指导咱们，一个类对另外一个类的依赖应该创建在最小的接口上。相比于抽象类 FlyCar，接口 Aircraft 能最大限度的减小对外暴露的接口，并隐藏细节，更符合这一原则。

因此说啊，面向对象只是指导咱们编程的思想，而非条条框框。在实际开发中，具体使用抽象类仍是接口，并无绝对限制，而是取决于你的业务场景和架构设计。

5. 总结

好了，本次关于接口与抽象类的总结就到这儿，你完全弄懂了吗？下期分享再见~

欢迎关注个人公众号“伯特说”：