这次,彻底弄懂接口及抽象类


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

抽象类及其作用

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

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

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

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

接口及其作用

下面我们来看看接口,假使我研发出来一台会飞的汽车“伯特莱斯”(Bote-Royce),在程序中定义如下:

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

    /**
     * 可以飞
     */
    void fly() {
        System.out.println("假装会飞~");
    }
}

看起来没问题:

  1. BoteRoyce extends Car:表达这是一辆汽车;
  2. 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 即为接口,我们通常使用接口对行为进行抽象。

接口和抽象类的区别

关于二者的区别,可以结合前面的例子,来加深理解。

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

而接口是对行为的抽象,表达的是 like a 的关系。比如:Bote-Royce like a Aircraft(像飞行器一样可以飞),但其本质上 is a Car。接口的核心是定义行为,即实现类可以做什么,至于实现类主体是谁、是如何实现的,接口并不关心。

接口与抽象类的使用场景

熟悉 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 能最大限度的减少对外暴露的接口,并隐藏细节,更符合这一原则。

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

总结

好了,本次关于接口与抽象类的总结就到这儿,你彻底弄懂了吗?下期分享再见~

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值