抽象类工厂在父类中定义创建子类的方法，是一种设计模式的实现方式。这种模式的核心思想是通过一个抽象类来定义创建对象的接口，而具体的创建逻辑则由该抽象类的子类来实现

抽象类中声明abstract Product createProduct()是工厂方法模式的必要起点，子类必须用new实现具体类型创建，且返回抽象类型Product以保证多态；使用抽象类而非接口可共享状态和初始化逻辑，并在编译期强制实现。

抽象类里定义 createProduct() 方法算不算工厂模式

不算严格意义上的工厂模式，但属于“工厂方法模式”的雏形。关键看子类是否覆盖该方法并返回具体类型实例——如果只是空实现或直接 new 具体类，那只是普通模板方法；只有当父类只声明、子类负责 new 出不同子类对象时，才构成工厂方法。

• abstract class ProductFactory 中声明 abstract Product createProduct(); 是必要起点
• 子类必须用 new ConcreteProductA() 或 new ConcreteProductB() 实现，不能在父类里写死
• 如果父类里写了 return new DefaultProduct();，那就不是工厂，是默认构造逻辑

为什么不用接口而用抽象类来定义工厂

抽象类能提供部分共用逻辑，比如初始化配置、日志记录、参数校验，而接口（Java 8 前）无法包含实现。现在虽有 default 方法，但抽象类仍更适合需要共享状态或复杂初始化的场景。

• 需要共享字段（如 protected final Config config;）→ 只能用抽象类
• 想在 createProduct() 调用前统一做权限检查 → 抽象类里套一层非 abstract 的 getProduct() 方法更自然
• 接口 + default 方法容易掩盖子类未重写的事实，运行时才暴露问题；抽象类强制子类实现，编译期就报错

createProduct() 返回 Product 还是 Object

必须返回抽象类型（如 Product），不能是 Object 或泛型裸类型。否则调用方要强转，失去多态意义，也破坏了工厂封装性。

• 返回 Object：调用方得写 (ConcreteProductA) factory.createProduct(); → 类型不安全，IDE 提示警告
• 返回 Product：直接 product.use();，子类行为由运行时决定
• 泛型写法如 T createProduct() 看似灵活，但实际使用时类型擦除，常导致 ClassCastException，慎用

常见错误：在抽象工厂类里 new 子类导致循环依赖

最典型的是抽象类里写了 new ConcreteFactoryImpl()，结果这个子类又继承自它——编译不过，或者启动时报 NoClassDefFoundError。

• 抽象类只声明方法，绝不 new 任何具体子类
• 工厂实例应由外部创建（如 Spring 容器、手动 new），而非让抽象类自己构造自己
• 测试时若用 new 模拟子类，注意别在静态块或字段初始化里触发子类加载

抽象类工厂真正的难点不在语法，而在职责边界：它不负责对象生命周期管理，也不该持有具体类名字符串去反射创建——那是简单工厂或抽象工厂的变体。一旦开始 parse 类名、读配置、调反射，就该换思路了。