本文介绍如何通过策略模式与多态重构臃肿的 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 类型开始，为其提取专属渲染器，你将立刻感受到清晰度与可控性的提升。
