面向对象设计：策略模式优化渲染逻辑

本文深入探讨了如何运用策略模式与多态思想彻底重构混乱臃肿的UI渲染逻辑，将原本混杂在数据模型（如Row）中上千行的HTML生成、事件绑定、验证和上传等职责剥离出来，交由类型专属的渲染器（如SaleRecordRenderer、ImageUploadRenderer）负责；通过统一接口、动态注册与轻量模型委托，实现数据与视图的真正解耦，显著提升代码可维护性、可测试性、可扩展性及团队协作效率，同时兼顾安全性、性能优化与服务端渲染支持——这不仅是一次代码层面的重构，更是迈向健壮、可持续演进前端架构的关键实践。

本文介绍如何通过策略模式与多态重构臃肿的 UI 渲染逻辑，将数据模型（Collection/Row）与视图呈现（HTML 生成、交互处理、验证等）彻底分离，提升可维护性与可扩展性。

本文介绍如何通过策略模式与多态重构臃肿的 UI 渲染逻辑，将数据模型（Collection/Row）与视图呈现（HTML 生成、交互处理、验证等）彻底分离，提升可维护性与可扩展性。

在现代 Web 应用开发中，当业务数据模型（如 Collection 和 Row）同时承担数据管理、状态维护、DOM 渲染、事件绑定、表单验证乃至文件上传等多重职责时，代码极易膨胀——正如问题中描述的“单个 Row 对象超 1000 行”，不仅难以测试、调试成本高，更严重阻碍功能迭代。根本症结在于违反单一职责原则（SRP）与关注点分离（SoC）。解决方案并非简单拆分文件或新建工具类，而应借助面向对象设计的核心思想进行结构性重构。

✅ 推荐方案：策略模式 + 多态渲染（Polymorphic Rendering）

核心思路是：让每种数据类型（如 SaleRecord、UserProfile、ProductImage）拥有专属的渲染器（Renderer），并通过统一接口实现多态调用。数据模型仅负责持有数据与委托渲染，不再感知 HTML 结构或 DOM 操作细节。

? 实现步骤示意

1. 定义抽象渲染器接口
   所有渲染器实现统一方法（如 render(row) 和 bindEvents(el, row)），确保可插拔：

// renderer.js
class Renderer {
  render(row) { throw new Error('render() must be implemented'); }
  bindEvents(container, row) { /* 可选：默认空实现 */ }
}

2. 为不同数据类型创建具体渲染器
   每个子类专注一种业务场景的 UI 逻辑，互不干扰：

// sale-record-renderer.js
class SaleRecordRenderer extends Renderer {
  render(row) {
    return `
      <tr data-id="${row.id}">
        <td><strong>${row.customerName}</strong></td>
        <td>$${(row.amount / 100).toFixed(2)}</td>
        <td>&lt;input type=&quot;checkbox&quot; ${row.isPaid ? &apos;checked&apos; : &apos;&apos;}&gt;</td>
        <td><button class="btn-edit">Edit</button></td>
      </tr>
    `;
  }

  bindEvents(container, row) {
    container.querySelector('.btn-edit').addEventListener('click', () => {
      openSaleEditor(row);
    });
  }
}

// image-upload-renderer.js
class ImageUploadRenderer extends Renderer {
  render(row) {
    return `
      <div class="image-row">
        <img src="${row.thumbnailUrl}" alt="Preview">
        &lt;input type=&quot;file&quot; accept=&quot;image/*&quot; data-row-id=&quot;${row.id}&quot;&gt;
        <span class="status">${row.uploadStatus || 'Ready'}</span>
      </div>
    `;
  }

  bindEvents(container, row) {
    const input = container.querySelector('input[type="file"]');
    input.addEventListener('change', (e) => this.handleFileUpload(e, row));
  }

  handleFileUpload(e, row) { /* 专用上传逻辑 */ }
}

3. 数据模型轻量化：只持引用，不写 HTML
   Row 不再包含千行渲染代码，而是根据类型动态选择渲染器：

// row.js
class Row {
  constructor(data, rendererRegistry = defaultRendererRegistry) {
    this.data = data;
    this.renderer = rendererRegistry.get(data.type); // 如 'sale-record' → SaleRecordRenderer
  }

  toHtml() {
    return this.renderer.render(this);
  }

  attachTo(container) {
    const el = document.createElement('div');
    el.innerHTML = this.toHtml();
    container.appendChild(el.firstElementChild);
    this.renderer.bindEvents(el.firstElementChild, this);
  }
}

4. 注册中心统一管理映射关系
   解耦类型与渲染器，便于配置与测试：

// renderer-registry.js
const rendererRegistry = new Map();

rendererRegistry.set('sale-record', new SaleRecordRenderer());
rendererRegistry.set('user-profile', new UserProfileRenderer());
rendererRegistry.set('product-image', new ImageUploadRenderer());

export function getRenderer(type) {
  const renderer = rendererRegistry.get(type);
  if (!renderer) throw new Error(`No renderer registered for type: ${type}`);
  return renderer;
}

⚠️ 关键注意事项

• 避免“渲染器”变相成为新上帝对象：每个渲染器仍需遵守 SRP —— 仅处理 该类型 的展示与轻量交互；复杂业务逻辑（如校验规则、API 调用）应下沉至独立 Service 层。
• DOM 操作需谨慎封装：推荐使用 document.createElement 或轻量模板库（如 HyperHTML、htm），避免直接拼接字符串带来的 XSS 风险与可维护性问题。
• 性能考量：对高频更新的列表（如实时表格），需结合虚拟滚动、事件委托（而非每个 Row 绑定事件）及 requestIdleCallback 优化。
• 服务端渲染（SSR）友好性：此模式天然支持同构渲染 —— 渲染器可同时运行于 Node.js（生成初始 HTML）与浏览器（补全交互）。

? 总结

与其在原有结构上“打补丁”（如拆分 collection_displayBehaviours.js）或退化为过程式工具函数（如 htmlTableConstructor.js），不如拥抱多态：用类型驱动行为，用组合替代继承，用协议（接口）保障协作。这不仅是代码组织方式的升级，更是构建可演进、易测试、团队协作友好的前端架构的关键一步。重构起点不必宏大——从一个最复杂的 Row 类型开始，为其提取专属渲染器，你将立刻感受到清晰度与可控性的提升。

本篇关于《面向对象设计：策略模式优化渲染逻辑》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！