Java 中抽象类为何既能包含抽象方法又能包含具体实现方法？

抽象类之所以能同时容纳抽象方法和具体实现，核心在于它扮演了双重角色：既要强制子类实现关键行为，又要提供通用逻辑的复用。这里的“abstract”修饰符，标识的是“类不能被直接实例化”，而不是“所有方法都得是空的”。

在Ja va里，“abstract”这个词确实容易让人产生字面误解——仿佛它就意味着“完全没有实现”。但实际上，abstract修饰符作用于类时，表达的是“该类不能被直接实例化”，而非“其中所有方法都必须为空”。这正是抽象类区别于接口的关键设计哲学：它既承担契约约束（通过抽象方法），又提供可复用的基础实现（通过具体方法）。

抽象类的双重能力：契约 + 复用

一个抽象类可以混合声明两类方法：

• 抽象方法：无方法体（即 {} 缺失），以 abstract 修饰，必须由非抽象子类实现；
• 具体方法：拥有完整实现，可被子类直接继承调用，也可被 @Override 重写。

abstract class Shape {
    // 抽象方法：定义子类必须实现的行为
    public abstract double area();

    // 具体方法：提供通用逻辑，子类可直接复用
    public void describe() {
        System.out.println("This is a geometric shape.");
    }

    // 静态方法、final 方法、构造器等也均可存在
    public static String getShapeType() {
        return "2D";
    }
}

class Circle extends Shape {
    private final double radius;

    public Circle(double radius) {
        this.radius = radius;
    }

    @Override
    public double area() {
        return Math.PI * radius * radius; // 实现抽象方法
    }
}

调用示例：

Circle c = new Circle(5.0);
c.describe();      // ✅ 直接调用父类具体方法
System.out.println(c.area()); // ✅ 调用子类实现的抽象方法
// new Shape();   // ❌ 编译错误：无法实例化抽象类

为什么这样设计？——面向对象的现实需求

接口（Interface）强调“能做什么”（what），适合定义纯粹契约（如 Runnable.run()）；而抽象类更侧重“是什么 + 怎么做一部分”（what + partial how），适用于具有共同状态和基础行为的类族。举个例子：

• 所有 Animal 子类都应实现 makeSound()（抽象），但共享 breathe() 的相同实现（具体）；
• JFrame 是 ja va.awt.Frame 的子类，而后者继承自抽象类 Window —— 它封装了窗口生命周期管理等共通逻辑，同时留出 paint() 等钩子供子类定制。

注意事项：

• 抽象类可含构造器（用于初始化共用字段），但仅能被子类调用（super(...)）；
• abstract 方法不能是 private、static 或 final（违背“强制重写”语义）；
• 自 Ja va 8 起，接口也可含 default 和 static 方法，但接口仍不能定义实例字段或构造器，这是抽象类不可替代的根本优势。

总的来说，抽象类不是“全空模板”，而是受控的半成品基类——它用抽象方法划定扩展边界，用具体方法沉淀稳定逻辑，从而在灵活性与复用性之间取得精巧平衡。