JavaScript策略模式：用对象映射替代if-else分支

一、传统分支结构的痛点与重构诉求

在电商订单处理、活动状态流转、权限校验等场景中，往往需要依据给定的枚举状态执行不同的业务逻辑。最直接的编写方式是直接堆叠分支条件：

// 传统多重 if-else 分支模式
function handleOrderStatus(status, order) {
  if (status === 'UNPAID') {
    sendPaymentReminder(order);
    updateOrderCountdown(order);
    return 'WAIT_PAY';
  } else if (status === 'PAID') {
    allocateInventory(order);
    notifyWarehouse(order);
    return 'PROCESSING';
  } else if (status === 'SHIPPED') {
    trackLogistics(order);
    sendDeliverySms(order);
    return 'IN_TRANSIT';
  } else if (status === 'REFUNDING') {
    freezeAsset(order);
    auditRefundRequest(order);
    return 'REFUND_AUDIT';
  } else {
    logUnknownStatus(status, order);
    return 'UNKNOWN';
  }
}

上述代码在业务初期分支较少时尚能运作，但随着版本迭代，其工程弊端会迅速显现：

• 圈复杂度（Cyclomatic Complexity）持续攀升：每个 else if 都会引入新的判定路径。如果函数内存在 8 个分支，测试该函数就需要准备至少 8 组测试用例，函数整体的稳定性维护成本呈线性增长。
• 破坏开闭原则（Open-Closed Principle）：每当新增一种订单状态或调整某个分支的实现细节时，必须直接修改包含全量状态的主干函数，极易产生意外的回归风险（Regression Bugs）。
• 作用域交叉与心智负担：若采用 switch-case，由于各个 case 共享同一个块级作用域，变量重名时需额外嵌套花括号，漏写 break 还会引发难以察觉的分支击穿隐患。
• 单测难以独立隔离：无法针对单一状态的处理逻辑编写独立的单元测试，所有断言都必须穿透整个主干函数。

二、对象映射实现策略模式的核心思路与基础范式

在策略模式的经典定义中，包含三项核心角色：环境上下文（Context）、策略接口（Strategy）和具体策略实现（ConcreteStrategy）。在 JavaScript 中，函数可直接作为变量传递和存储。因此，一个纯 JavaScript 对象的键名即可充当分发标志，对象的键值即为封装好的具体策略函数。

1. 策略字典的基础定义与分发

将各个分支中的行为提取为独立纯函数，并组织为一个静态映射字典：

// 1. 提取各状态的具体策略函数
const orderStrategies = {
  UNPAID(order) {
    sendPaymentReminder(order);
    updateOrderCountdown(order);
    return 'WAIT_PAY';
  },
  PAID(order) {
    allocateInventory(order);
    notifyWarehouse(order);
    return 'PROCESSING';
  },
  SHIPPED(order) {
    trackLogistics(order);
    sendDeliverySms(order);
    return 'IN_TRANSIT';
  },
  REFUNDING(order) {
    freezeAsset(order);
    auditRefundRequest(order);
    return 'REFUND_AUDIT';
  }
};

// 2. 默认兜底策略
const defaultOrderStrategy = (order, status) => {
  logUnknownStatus(status, order);
  return 'UNKNOWN';
};

// 3. 运行态统一调度入口
function handleOrderStatus(status, order) {
  const strategy = orderStrategies[status] ?? defaultOrderStrategy;
  return strategy(order, status);
}

通过这一重构，handleOrderStatus 函数由原先的一长串逻辑判断直接收缩为三行代码。寻找策略的操作变成了哈希表的键值查找，执行时间复杂度恒定为 O(1)，且圈复杂度降为 1。

三、复杂业务场景下的进阶实现技巧

真实业务场景往往比单一枚举判断更为复杂，例如涉及多维度参数、动态复合键、异步操作及安全拦截等。以下是四种常见的工程进阶手段。

1. 动态上下文（Context）对象解耦

当各个策略需要的参数数量不一致时，切忌在策略入口处传递松散的长参数列表。推荐将参数统一封装为上下文对象 context：

const strategyMap = {
  EXPORT_EXCEL: (ctx) => generateExcel(ctx.data, ctx.config),
  EXPORT_CSV: (ctx) => generateCsv(ctx.data, ctx.delimiter),
  EXPORT_PDF: (ctx) => generatePdf(ctx.data, ctx.templateId, ctx.watermark)
};

function exportReport(formatType, context) {
  const exporter = strategyMap[formatType];
  if (!exporter) {
    throw new Error(`不支持的导出格式: ${formatType}`);
  }
  return exporter(context);
}

2. 多元条件匹配：复合键（Compound Key）技巧

当业务逻辑由多个条件同时决定时（例如“用户角色”与“操作动作”联合判定），传统写法容易产生双层嵌套 if。利用模板字符串将多维条件合并为复合键，可将多维网状判断拍平为一维离散查表：

// 复合键映射：${role}_${action}
const permissionStrategies = {
  'ADMIN_DELETE': (ctx) => executeHardDelete(ctx),
  'ADMIN_EXPORT': (ctx) => exportFullData(ctx),
  'USER_DELETE': (ctx) => executeSoftDelete(ctx),
  'USER_EXPORT': (ctx) => exportMaskedData(ctx),
  'GUEST_VIEW': (ctx) => allowReadOnly(ctx)
};

function dispatchAction(role, action, ctx) {
  const key = `${role}_${action}`;
  const strategy = permissionStrategies[key] ?? fallbackPermissionDenied;
  return strategy(ctx);
}

3. 异步策略总线（Async Strategy Dispatcher）

当具体策略包含网络请求、数据库读写等异步流程时，策略函数直接声明为 async，分发器通过统一的 await 接收处理结果：

const asyncPaymentStrategies = {
  async WECHAT(order) {
    const res = await callWechatPayApi(order);
    return res.prepayId;
  },
  async ALIPAY(order) {
    const res = await callAlipayGateway(order);
    return res.formHtml;
  },
  async UNIONPAY(order) {
    return await callUnionPayDirect(order);
  }
};

async function processPayment(channel, order) {
  const strategy = asyncPaymentStrategies[channel];
  if (!strategy) {
    throw new UnsupportedPaymentChannelError(channel);
  }
  return await strategy(order);
}

四、对象映射策略与传统分支的选型权衡

策略模式虽然能够显著解耦代码，但并非所有条件语句都适合采用对象映射进行改造。工程实践中应基于具体场景权衡取舍。

五、工程实践规范与排坑指南

在大型项目或生产环境中落地对象映射策略模式时，需注意以下四个关键要点：

1. 避免在函数内部重复创建策略对象

若将策略对象声明在分发函数体内部，每次调用该函数都会在堆内存中重新分配对象并实例化函数闭包，造成不必要的 GC 压力。正确的做法是将策略字典定义在模块顶层作用域，使其在应用生命周期内单例复用：

// 错误示例：每次函数调用都重新创建映射表
function badDispatch(type, data) {
  const map = {
    A: () => doA(data),
    B: () => doB(data)
  };
  return map[type]?.();
}

// 正确示例：模块顶层常量定义，复用策略引用
const STRATEGY_REGISTRY = Object.freeze({
  A: (data) => doA(data),
  B: (data) => doB(data)
});

function goodDispatch(type, data) {
  return (STRATEGY_REGISTRY[type] ?? fallback)(data);
}

2. TypeScript 严格类型约束与穷尽性保障

结合 TypeScript 的 Record 泛型，可以在编译阶段对策略字典进行完整性约束。当业务新增枚举成员时，若策略字典漏写了对应处理函数，编译器将直接报错拦截：

type OrderStatus = 'DRAFT' | 'SUBMITTED' | 'APPROVED' | 'REJECTED';

type OrderHandler = (orderId: string) => Promise<boolean>;

// 使用 Record 确保所有枚举状态均有对应的策略实现
const statusStrategies: Record<OrderStatus, OrderHandler> = {
  DRAFT: async (id) => handleDraft(id),
  SUBMITTED: async (id) => handleSubmit(id),
  APPROVED: async (id) => handleApprove(id),
  REJECTED: async (id) => handleReject(id)
};

3. 策略函数的纯度与状态隔离

各个策略函数应当保持较高的纯度，不应隐式读写或篡改外部模块的共享变量。若策略需要外部依赖（如网络库、用户会话、配置项），应一律通过参数显式注入，以便于进行单元测试和 Mock 替换。

4. 拆分大型策略为独立文件模块

当各个策略函数的代码量较大（例如单策略超过 50 行）时，应避免将所有策略塞进同一个文件。推荐建立 strategies/ 目录，每种策略独立为一个文件，并在 index.js 中统一聚集导出：

// 目录结构规范推荐
// src/services/order/
// ├── strategies/
// │   ├── paid.strategy.js
// │   ├── shipped.strategy.js
// │   ├── refund.strategy.js
// │   └── fallback.strategy.js
// ├── order.registry.js   # 聚集注册字典
// └── order.service.js    # 业务分发主入口

总结

使用对象映射实现策略模式，是 JavaScript 语言特性的经典应用。它将命令式的流程控制转化为数据驱动的查表计算，在消除深层嵌套和复杂圈复杂度的同时，为业务系统的横向扩展奠定了坚实的架构基础。理解这一模式并在适宜的复杂度场景下果断重构，能让代码库保持长期的清晰、稳健与可测试性。