抽象类中声明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 extends product> T createProduct()</t>看似灵活，但实际使用时类型擦除，常导致 ClassCastException，慎用
常见错误：在抽象工厂类里 new 子类导致循环依赖
最典型的是抽象类里写了 new ConcreteFactoryImpl()，结果这个子类又继承自它——编译不过，或者启动时报 NoClassDefFoundError。
立即学习“Java免费学习笔记（深入）”；
- 抽象类只声明方法，绝不 new 任何具体子类
- 工厂实例应由外部创建（如 Spring 容器、手动 new），而非让抽象类自己构造自己
- 测试时若用
new模拟子类，注意别在静态块或字段初始化里触发子类加载
