本文介绍如何通过多态重构将数据对象（如 row/collection）的渲染职责与业务逻辑彻底分离，避免千行渲染代码堆积在模型类中，提升可维护性与可扩展性。
本文介绍如何通过多态重构将数据对象（如 row/collection）的渲染职责与业务逻辑彻底分离，避免千行渲染代码堆积在模型类中，提升可维护性与可扩展性。
在 Web 应用开发中，当“数据对象”（如 Row 或 Collection）同时承担数据管理、状态校验、用户交互和 HTML 渲染等多重职责时，极易陷入“胖模型”困境——例如一个 Row 类膨胀至 1000+ 行，混杂着 渲染逻辑、文件上传处理、表单验证规则等，导致修改风险高、测试困难、复用性差。
根本解法不是简单地按文件拆分（如 row.js + row_display.js），也不是引入一个全局“HTML 构造器”（如 HtmlTableConstructor）来集中渲染——后者会破坏封装性，使渲染逻辑与数据语义脱钩，且难以支持差异化展示（如同一数据在列表页 vs 详情页需不同 UI）。
✅ 正确路径是：以多态驱动渲染职责下沉，让每种数据类型自知如何呈现自己。
其核心思想源自重构经典实践——“用多态取代条件逻辑”（Replace Conditional with Polymorphism）。不再在 Row.draw() 中写大量 if/else 或 switch 判断字段类型：
// ❌ 反模式：条件渲染，难以维护与扩展
draw() {
switch(this.type) {
case 'sale-record':
return `<tr><td>${this.amount}</td><td><input type="checkbox" checked="${this.isPaid}"></td></tr>`;
case 'user-profile':
return `<tr><td>${this.name}</td><td><img src="${this.avatarUrl}" alt="面向对象设计中的渲染逻辑解耦：使用多态替代条件分支实现职责分离" ></td></tr>`;
case 'product-item':
return `<tr><td><img src="${this.thumbnail}" alt="面向对象设计中的渲染逻辑解耦：使用多态替代条件分支实现职责分离" ></td><td>${this.title} <button onclick="edit(${this.id})">Edit</button></td></tr>`;
// …… 还有 10+ 种类型，持续增长
}
}而是定义统一渲染契约，并为每类业务实体创建专属渲染器（或直接让实体自身实现）：
// ✅ 接口契约（TypeScript 风格，JS 中可约定）
class Renderable {
render() {
throw new Error('Subclass must implement render()');
}
}
// 每个业务类型独立实现渲染逻辑
class SaleRecord extends Renderable {
constructor(data) {
super();
this.data = data;
}
render() {
return `
<tr class="sale-row">
<td class="amount">${this.data.amount.toFixed(2)}</td>
<td class="status">
<label><input type="checkbox" ${this.data.isPaid ? 'checked' : ''}> Paid</label>
</td>
</tr>
`;
}
}
class UserProfile extends Renderable {
constructor(data) {
super();
this.data = data;
}
render() {
return `
<tr class="user-row">
<td>${this.data.name}</td>
<td><img src="${this.data.avatarUrl || '/placeholder.png'}" style="max-width:90%" alt="Avatar"></td>
</tr>
`;
}
}此时，Collection 仅需委托渲染，完全不感知具体类型：
class Collection {
constructor(rows = []) {
this.rows = rows; // 全为 Renderable 实例
}
renderTable() {
const rowsHtml = this.rows.map(row => row.render()).join('');
return `
<table class="data-table">
<thead><tr><th>Name</th><th>Preview</th></tr></thead>
<tbody>${rowsHtml}</tbody>
</table>
`;
}
}? 关键优势：
- 开闭原则友好：新增数据类型（如 InventoryItem）只需新增一个 Renderable 子类，无需修改 Collection 或现有 Row 逻辑；
- 关注点分离：SaleRecord 聚焦销售域逻辑与 UI 呈现；校验、保存等行为仍可保留在对应领域类中（甚至通过组合注入 Validator 或 ApiService）；
- 可测试性强：每个 render() 方法可独立单元测试，输入数据 → 断言 HTML 结构；
- 支持组合与装饰：例如为所有渲染器添加 loading 状态，可封装 withLoading(Renderable) 工厂函数。
⚠️ 注意事项：
- 避免过度设计：若仅有 2–3 种简单类型，适度使用工厂函数 + 策略对象（Strategy Pattern）亦可接受；
- 渲染器应保持无副作用：render() 应纯函数式返回 HTML 字符串（或虚拟 DOM 节点），不操作 DOM、不发起请求、不修改自身状态；
- 在现代框架（React/Vue）中，该思想自然演进为「组件化」——每个业务实体对应一个受控组件，props 即数据，render 即 JSX/Template，本质仍是多态渲染。
总结：封装渲染逻辑的最优模式，不是物理拆分文件或创建通用构造器，而是通过多态将“如何画自己”的知识交还给数据本身。这既符合面向对象的封装本质，也为系统长期演进提供了清晰、稳健的扩展骨架。
