本文介绍如何通过多态设计模式将数据模型与视图渲染职责分离，避免巨型“绘制函数”和冗长类型判断，提升前端组件的可维护性与可扩展性。
本文介绍如何通过多态设计模式将数据模型与视图渲染职责分离，避免巨型“绘制函数”和冗长类型判断，提升前端组件的可维护性与可扩展性。
在现代 Web 应用中，当业务数据结构日益复杂（如销售记录、用户档案、媒体条目等），若将所有渲染逻辑硬编码在 Row 或 Collection 类中——例如用大量 if/else 或 switch 判断字段类型来决定渲染为 、 还是富文本编辑器——不仅导致单个类膨胀至千行以上，更严重破坏了单一职责原则（SRP）和开闭原则（OCP）：新增一种数据类型，就要修改原有类；修复某类渲染 Bug，可能意外影响其他类型。
核心解法：用多态替代条件分支
不再让通用 Row 类承担全部渲染责任，而是为每种语义化数据类型定义专属的渲染策略类，统一实现 render() 接口：
此时，Row 类退化为轻量数据容器，仅负责持有原始数据并委托给对应渲染器：
关键优势与实践要点
：
✅
零条件判断
：新增数据类型只需新增一个 Renderable 子类，无需修改任何现有类；
✅
关注点分离
：Row 专注数据封装与生命周期管理，渲染器专注 HTML 构建与交互绑定；
✅
可测试性强
：每个渲染器可独立单元测试，输入数据 → 验证输出 HTML 结构；
✅
支持组合扩展
：渲染器内部可复用通用工具（如表单验证器、文件上传器），也可嵌套其他渲染器（如 TableRenderer 包含多个 RowRenderer）；
⚠️
注意事项
：
避免过度拆分：若仅有 2–3 种简单类型，可先用工厂函数 + 策略映射表过渡（如 rendererMap[type] = () => {...}）；
渲染器应
只生成 HTML 字符串或 DOM 片段
，不直接操作全局 DOM 或发起网络请求——这些副作用应由更高层控制器（如 CollectionView）协调；
在框架环境（React/Vue）中，该模式自然映射为「组件化」：每个 Renderable 对应一个受控组件，Row 即为传递 props 的数据载体。
这种基于多态的渲染封装，不是简单的文件拆分（选项1）或工具类抽离（选项2），而是从设计层面重构职责边界——让代码结构忠实地反映业务语义，使系统随业务演进而优雅生长。
// 基础渲染接口（契约）
class Renderable {
render() {
throw new Error('Subclass must implement render()');
}
}
// 具体实现：销售记录行渲染器
class SaleRecordRenderer extends Renderable {
constructor(data) {
super();
this.data = data;
}
render() {
return `
${this.data.id}
$${this.data.amount.toFixed(2)}
`;
}
}
// 具体实现：用户头像渲染器
class AvatarRenderer extends Renderable {
constructor(data) {
super();
this.data = data;
}
render() {
return `
${this.data.userId}
`;
}
}class Row {
constructor(data, rendererClass) {
this.data = data;
this.renderer = new rendererClass(data); // 依赖注入具体策略
}
toHTML() {
return this.renderer.render(); // 多态调用，无 if/else
}
}
// 使用示例
const saleRow = new Row({ id: 101, amount: 299.99, date: '2024-05-20' }, SaleRecordRenderer);
const avatarRow = new Row({ userId: 7, avatarUrl: '/avatars/7.jpg' }, AvatarRenderer);
console.log(saleRow.toHTML()); // 渲染销售行
console.log(avatarRow.toHTML()); // 渲染头像行