abstract 抽象类

abstract 抽象类

1. 不能new抽象类，只能靠子类去实现它：约束！
2. 抽象类中可以写普通的方法~
3. 抽象的方法必须在抽象类中~
抽象的抽象：约束~

Action

package com.oop.demo08;

//abstract 抽象类：类 extends： 单继承    (接口可以多继承)
public abstract class Action {

    //约束~有人帮我们实现
    //abstract 抽象方法,只有方法的名字，没有方法的实现
    public abstract void doSomething();


    //1. 不能new抽象类，只能靠子类去实现它：约束！
    //2. 抽象类中可以写普通的方法~
    //3. 抽象的方法必须在抽象类中~
    //抽象的抽象：约束~

思考题？     
1.抽象类中存在构造器吗？
抽象类可以有构造器（甚至可以有多个重载的构造器），但有几个关键特点需要明确：
抽象类不能被直接实例化（new 抽象类() 会编译报错），但它的构造器依然会被执行 —— 当它的非抽象子类实例化时，会先调用抽象父类的构造器（遵循继承中 “先父后子” 的构造器执行规则）。
如果抽象类没有显式定义构造器，编译器会自动生成默认的无参构造器（和普通类一样）；如果显式定义了有参构造器，子类必须通过 super() 显式调用父类的构造器。
           
2.抽象类存在的意义？
抽象类的核心意义是 **“模板复用 + 强制约束”**，是对 “类的抽象”，而非 “对象的抽象”（接口更偏向对象行为的抽象），具体体现在以下 3 点：
①代码复用（核心价值）
抽象类可以包含非抽象的成员变量、普通方法、静态方法，这些内容可以被所有子类共享，避免子类重复编写相同逻辑。
比如：定义一个抽象类 Shape（图形），包含通用属性（如颜色）和通用方法（如获取颜色），子类 Circle、Rectangle 只需专注实现自己的 “计算面积” 抽象方法即可。
②强制子类实现核心行为
抽象类中的 abstract 方法没有具体实现，强制所有非抽象子类必须重写这些方法，保证了子类的行为一致性。
比如：抽象类 Vehicle 定义 abstract void run()，所有子类（Car、Bike）必须实现 “行驶” 逻辑，避免子类遗漏核心功能。
③约束类的设计边界
抽象类本身不能被实例化，意味着它只能作为 “父类模板” 存在，引导开发者按照 “抽象父类 → 具体子类” 的层级设计代码，符合面向对象的 “里氏替换原则”，让代码结构更清晰。

}

A

package com.oop.demo08;

//抽象类的所有方法，继承了它的子类，都必须要实现它的方法~  除非~子类也是 abstract 抽象类
public class A extends Action{
    @Override
    public void doSomething() {

    }
}