本文介绍如何通过策略模式与多态重构臃肿的 ui 渲染逻辑，将数据模型（Collection/row）与视图呈现（html 生成、交互处理、验证等）彻底分离，提升可维护性与可扩展性。
本文介绍如何通过策略模式与多态重构臃肿的 ui 渲染逻辑，将数据模型（collection/row）与视图呈现（html 生成、交互处理、验证等）彻底分离，提升可维护性与可扩展性。
在现代 Web 应用开发中，当业务数据模型（如 Collection 和 Row）同时承担数据管理、状态维护、dom 渲染、事件绑定、表单验证乃至文件上传等多重职责时，代码极易膨胀——正如问题中描述的“单个 Row 对象超 1000 行”，不仅难以测试、调试成本高，更严重阻碍功能迭代。根本症结在于违反单一职责原则（SRP）与关注点分离（SoC）。解决方案并非简单拆分文件或新建工具类，而应借助面向对象设计的核心思想进行结构性重构。
✅ 推荐方案：策略模式 + 多态渲染（Polymorphic Rendering）
核心思路是：让每种数据类型（如 SaleRecord、UserProfile、ProductImage）拥有专属的渲染器（Renderer），并通过统一接口实现多态调用。数据模型仅负责持有数据与委托渲染，不再感知 HTML 结构或 DOM 操作细节。
? 实现步骤示意
- 定义抽象渲染器接口
所有渲染器实现统一方法（如 render(row) 和 bindEvents(el, row)），确保可插拔：
// renderer.js class Renderer { render(row) { throw new Error('render() must be implemented'); } bindEvents(container, row) { /* 可选：默认空实现 */ } }- 为不同数据类型创建具体渲染器
每个子类专注一种业务场景的 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><input type="checkbox" ${row.isPaid ? 'checked' : ''}></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"> <input type="file" accept="image/*" data-row-id="${row.id}"> <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) { /* 专用上传逻辑 */ } }- 数据模型轻量化：只持引用，不写 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); } }- 注册中心统一管理映射关系
解耦类型与渲染器，便于配置与测试：
// 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 类型开始，为其提取专属渲染器，你将立刻感受到清晰度与可控性的提升。