MVVM中条件逻辑与代码重复的取舍：只读模块最优方案

这是UI开发里很常见的状态控制场景，我会优先推荐对方案二做轻量化改进，既保留模块化的优势，又能把代码重复降到最低——毕竟原方案一的条件逻辑堆砌问题，长期来看会变成很难维护的技术债务，而方案二的重复问题其实是可以通过合理的抽象解决的。

先拆解下原方案的核心痛点 #

• 方案一的问题：短期看没有代码重复，但随着业务迭代，你大概率会遇到更多状态需求（比如新增"预览态""草稿态"），到时候View和ViewModel里会塞满if (isReadOnly) { ... } else { ... }的判断，代码可读性和可维护性会急剧下降，甚至出现逻辑漏洞。
• 方案二的问题：纯拆分确实会导致代码重复，但只要做一层基础抽象，就能把重复率降到几乎为零。

优化后的具体实现思路 #

1. View层：核心展示与交互分离

• 抽离无交互的基础展示组件：比如把UserProfileView里的纯渲染逻辑（只显示姓名、邮箱等数据）拆成BaseUserProfileView，这个组件不处理任何点击、输入事件，只负责接收Model数据并渲染。
• 分别创建状态专属包装组件：
  • EditableUserProfileView：组合BaseUserProfileView，加上输入框、保存按钮等交互控件，绑定编辑相关的事件。
  • ReadOnlyUserProfileView：同样组合BaseUserProfileView，把输入框替换成静态文本，隐藏/置灰所有操作按钮，或者直接禁用交互（比如给控件加disabled属性）。

这样核心展示代码只写一次，两个版本的差异仅仅是交互层的包装，完全没有重复的渲染逻辑。

2. ViewModel层：基础逻辑复用+状态专属扩展

• 保留基础ViewModel：比如BaseUserViewModel，实现所有通用逻辑（数据加载、数据格式转换、通用状态管理等），这部分是所有状态共享的。
• 继承实现状态专属ViewModel：
  • EditableUserViewModel：继承自BaseUserViewModel，新增编辑、保存、校验等交互方法，维护可编辑状态的属性。
  • ReadOnlyUserViewModel：同样继承自BaseUserViewModel，重写那些需要禁用的方法（比如save()方法直接返回提示或空实现），并把可编辑相关的属性设为只读（或者直接移除）。

3. 配置驱动的实例化

在模块的入口处（比如路由配置、模块初始化代码），根据配置参数isReadOnly来决定实例化哪个版本的View和ViewModel：

// 伪代码示例
if (config.isReadOnly) {
  return new ReadOnlyUserProfileView(new ReadOnlyUserViewModel());
} else {
  return new EditableUserProfileView(new EditableUserViewModel());
}

完全不需要在组件内部加条件判断，每个组件只专注自己的状态逻辑。

为什么这是最优解？ #

• 避免条件地狱：每个组件/ViewModel只负责一种状态的逻辑，代码清晰，后续新增状态（比如"审核态"）只需要新增一对包装组件和ViewModel子类即可，不会影响现有代码。
• 最小化代码重复：核心逻辑都在基础层复用，只有交互相关的差异化代码是各自实现的，重复度极低。
• 符合单一职责原则：展示、交互、业务逻辑各司其职，后续修改某一种状态的逻辑时，不会影响到其他状态。

例外情况 #

如果你的模块非常小，并且可以确定未来不会扩展更多状态，方案一也可以临时用（毕竟实现更快），但从长期维护的角度来说，优化后的方案二更值得选择。

内容的提问来源于stack exchange，提问作者Reed