计算属性名不是开闭原则的实现机制，而是JavaScript中辅助动态注册策略的语法糖；真正支撑开闭原则的是策略模式——通过统一接口、独立策略封装与动态注册，使新增功能无需修改原有代码。
计算属性名本身不是开闭原则的实现机制，但它可以在特定语言（如 JavaScript）中辅助达成“对扩展开放、对修改关闭”的目标——前提是它被用于解耦行为注入、避免硬编码分支，而非替代抽象设计。
计算属性名的作用边界
在 JavaScript 中，计算属性名（[key]）允许动态设置对象键名，例如：
const handlers = {
[`on${event}`]: () => { /* 处理逻辑 */ }
};但这只是语法糖，不构成设计原则。它无法单独保证开闭性；若 handler 逻辑仍写死在 if-else 或 switch 中，新增事件仍需修改原对象或函数体，违反“对修改关闭”。
真正支撑开闭原则的是策略容器 + 动态注册
要让系统可扩展且不改旧代码，关键在于把“行为”和“调度”分离。计算属性名可作为注册环节的便利工具，但核心是策略模式结构：
- 定义统一接口：比如 execute(input) 方法签名
- 每个新功能封装为独立策略对象（类或函数）
- 提供注册入口（如 register(name, strategy)），内部用 Map 或普通对象存储
- 使用计算属性名简化注册写法，例如：strategies[`validate_${rule}`] = validator
- 执行时通过名称查找并调用，不依赖 if 分支
一个轻量级示例（JavaScript）
假设做表单校验器：
class Validator {
constructor() {
this.rules = {};
}
// 扩展点：新增规则无需改 Validator 类体
register(ruleName, fn) {
this.rules[`validate_${ruleName}`] = fn; // 这里用了计算属性名
}
run(value, ruleName) {
const key = `validate_${ruleName}`;
if (!this.rules[key]) throw new Error(`No rule: ${ruleName}`);
return this.rules[key](value);
}
}
<p>// 新增手机号规则 —— 只加几行，不动原有代码
validator.register('phone', (v) => /^1[3-9]\d{9}$/.test(v));</p><p>// 新增邮箱规则 —— 同样只扩展，不修改
validator.register('email', (v) => v.includes('@'));此时 Validator 类本身已“关闭修改”，所有新规则都通过 register 注入，符合开闭原则。
注意常见误区
- 不要把所有逻辑塞进一个对象字面量里再用 [key] 动态访问——那只是把 if 换成 key 查找，本质仍是集中式维护，扩展仍需改该对象
- 计算属性名不能替代抽象层。没有接口约定、没有策略隔离，光靠动态键名无法应对行为差异大的场景（如面积计算中 Circle 和 Triangle 的公式完全不同）
- 在 TypeScript 或 Java 等强类型语言中，计算属性名不可用，此时必须依赖接口/抽象类 + 工厂或依赖注入来实现同等效果
