工厂模式和策略模式有什么区别？如何配合管理多种实现？

知识点详解：把创建选择与行为变化分别放好

从上传服务找出两个变化点

假设系统支持本地存储和对象存储。两者都能保存文件，但初始化参数不同：本地需要目录，对象存储需要客户端及桶配置。

第一个变化点是“如何取得一个可用的存储实现”。第二个变化点是“保存文件的行为如何执行”。把两者分开，上传业务才能只处理文件校验和调用。

如果每个调用处都重复判断存储类型、读取配置并创建客户端，新增一种实现就要到处修改。工厂负责收拢这部分创建和选择过程。

用一份小实现，看两种职责怎样配合

下面只展示职责，不执行真实存储 I/O。函数本身也可以作为策略，不必强行创建很多类。

type Saver = (name: string) => string;
const savers: Record<string, Saver> = {
  local: (name) => "local/" + name,
  cloud: (name) => "cloud/" + name,
};
function getSaver(kind: string): Saver {
  const saver = Object.hasOwn(savers, kind) ? savers[kind] : undefined;
  if (!saver) throw new Error("unsupported storage");
  return saver;
}
const saveFile = getSaver("cloud");
console.log(saveFile("report.pdf"));

savers = {
    "local": lambda name: "local/" + name,
    "cloud": lambda name: "cloud/" + name,
}

def get_saver(kind):
    if kind not in savers:
        raise ValueError("unsupported storage")
    return savers[kind]

save_file = get_saver("cloud")
print(save_file("report.pdf"))

getSaver/get_saver 集中选择实现，属于工厂或提供器职责；取得的可调用对象，表达不同的保存策略。这是一个简化注册表，不等于已经展示了所有工厂模式变体。

别把简单工厂、工厂方法和抽象工厂混为一谈

简单工厂可以集中按参数选择对象。工厂方法通常通过可覆盖的创建方法，让具体创建延后到相应实现。抽象工厂则关注一组相互配套的产品创建。

它们都与创建有关，但解决的问题不同。面试不能看到一个 get 方法就直接宣布“这一定是抽象工厂”。

策略则关注行为替换：调用方依赖统一接口或函数约定，具体行为可以独立变化。实现对照可参考项目源码中的 Factory Method 与 Strategy。

统一接口，还要统一行为契约

即使两个实现都有 save，也要说明它们返回什么、异常怎么表达、是否覆盖已有文件，以及操作是否支持重复执行。

否则调用方虽然不再检查类型，却仍然要为每种实现写特殊分支，抽象只是改了名字。

工厂还需要决定实例生命周期。对象存储客户端可能适合复用，本地操作也可能需要特定配置；不能每次调用都随意创建昂贵资源。

图：边界条件要在策略接口中约定清楚，而不是让每个实现各自定义一套行为。

面试官继续追问

策略模式能完全消除 if else 吗？

不能，也没有必要。选择处可能仍然需要条件或注册表。目标是让选择集中、行为可替换，而不是禁止所有条件语句。

Spring 注入实现后，还需要工厂吗？

如果容器已经提供固定实现，可以直接注入；如果需要按请求动态选择，可以使用明确的策略注册表。不要重复创建容器已有对象。

怎么测试是否设计过度？

看是否真的存在多种行为、变化是否频繁、调用处是否重复。少量稳定逻辑用简单函数也可能更清楚。

面试速记卡

• 工厂：管理对象创建与取得。
• 策略：管理同一行为的不同实现。
• 配合方式：工厂提供策略，业务调用统一约定。
• 统一接口：还要统一结果、异常和副作用契约。
• 抽象尺度：围绕真实变化，不为了模式名称增加层次。