工厂模式适合创建单一类型对象，抽象工厂模式用于创建一组相关或相互依赖的对象；FactoryMethod 子类应职责明确、避免条件判断；AbstractFactory 扩展困难时可拆分粒度或用泛型缓解；SimpleFactory 非 GoF 模式，适合小项目但违反单一职责；工厂类通常需单例并保证线程安全。
工厂模式适合创建单一类型对象，抽象工厂模式解决多系列对象组合创建
工厂模式（SimpleFactory 或 FactoryMethod）适用于同一类产品的不同实例，比如不同数据库驱动的 Connection 对象；抽象工厂模式（AbstractFactory）则用于创建一组相关或相互依赖的对象，比如一套 UI 组件（Button、Checkbox）在 Windows 和 macOS 下的不同实现。别硬套“更高级=更好”，用错场景反而增加维护成本。
FactoryMethod 的子类职责必须明确，否则容易退化成条件分支
FactoryMethod 模式靠子类决定实例化哪个具体类，但如果子类里又出现 if-else 或 switch 判断类型，就违背了初衷。常见错误是写成这样：
class SqlServerFactory extends DaoFactory {
@Override
public UserDao createUserDao() {
if ("mysql".equals(type)) { // ❌ 这里不该有判断逻辑
return new MySqlUserDao();
}
return new SqlServerUserDao();
}
}
正确做法是每个子类只负责一种确定实现：
-
MySqlFactory固定返回MySqlUserDao和MySqlOrderDao -
SqlServerFactory固定返回SqlServerUserDao和SqlServerOrderDao - 运行时通过配置或上下文选择具体工厂类，而不是让工厂自己做决策
AbstractFactory 接口设计不当会导致扩展困难
抽象工厂接口一旦定义，新增产品线（如加一个 ReportGenerator）就得改接口、改所有已实现类，违反开闭原则。实际中建议：
立即学习“Java免费学习笔记（深入）”；
- 用泛型或参数化方法缓解，例如
<T> T create(Class<T> clazz)，但会丢失编译期类型安全 - 拆分粒度：把「数据库访问层工厂」和「报表层工厂」分开，避免一个
AbstractFactory承担太多职责 - Spring 的
BeanFactory本质是抽象工厂的增强版，但它靠配置和反射解耦，不靠继承——面试时提这个能体现深度
面试常问：简单工厂算不算设计模式？
严格来说，SimpleFactory 不是 GoF 23 种设计模式之一，它只是编码技巧。关键区别在于：它把对象创建逻辑集中在一个类里，违反单一职责；而 FactoryMethod 把创建逻辑下放到子类，符合开闭原则。面试官如果追问“为什么不用简单工厂”，重点不是背定义，而是说清权衡：SimpleFactory 适合小项目快速验证，但类型一多，switch 分支就会散落在各处，测试和替换都麻烦。
真正容易被忽略的是：工厂类本身要不要单例？多数情况要，否则每次 new 工厂再 get 实例，等于没封装——但得确认线程安全，尤其是懒汉式单例没加 synchronized 或 volatile 就可能出问题。
