为什么首先有抽象类？

Question

我知道创建抽象类背后的概念用途，即为其子类定义一个公共接口，其中一些实现留给各个子类。

我的假设是否正确，即技术上不需要抽象类，因为无论如何您都可以覆盖超类方法？抽象类是否只是为了让开发人员更清楚类的意图而创建的？

我的意思的例子：

// Using an abstract class
abstract class Car
{
    int fuel;

    int getFuel()
    {
         return this.fuel;
    }

    abstract String getColor();
}

class RedCar extends Car
{
    String getColor()
    {
        return "red";
    }
}


// Without an abstract class
class Car
{
    int fuel;

    int getFuel()
    {
         return this.fuel;
    }

    String getColor()
    {
         return "defaultColor";
    }

class RedCar extends Car
{
    String getColor()
    {
        return "red";
    }
}

Answer 1

创建抽象类是为了让开发人员更清楚这些类的意图吗？

没错，但它也阻止了开发人员做“愚蠢”的事情。

例如，您不能创建抽象类的实例。在您的代码上下文中，创建“通用”Car 是没有意义的。您只能创建 BlueCar 或 RedCar 或其他一些子类。虽然anonymous subclass 的实例可能看起来像抽象类的实例，但它们最终是由子类 构造的。但是，如果您将Car 类抽象化，开发人员不会意外创建Car 的实例，因为编译器会报错。

抽象类还强制开发人员实现抽象方法。使用您的非抽象Car 类，我可以继承它而忘记我需要覆盖getColor。现在代码的其他一些部分可能会调用getColor 并得到一个无意义的结果“defaultcolor”。什么是默认颜色？将方法抽象化会迫使子类考虑实现所需的方法。

Answer 2

我认识的大多数人都避免使用抽象类。从应用程序程序员的角度来看，我的意见是应该避免使用抽象类。使用接口更加灵活，不会强迫您的工作遵循类层次结构。

有点正式：抽象类是严格的继承，而接口是组合。

抽象类有用的一个例子是在创建类库时。抽象类强制执行的层次结构可以使应用程序程序员更容易理解该库。但是，我确实认为这是以库的开发时间更长为代价的。