暗无天日
·
读：Immutability 不是万能药，它是一种权衡
💡
原文中文，约6100字，阅读约需15分钟。
📝
内容提要
不可变性是指数据创建后不再修改，常被视为函数式编程的原则。作者认为不可变性并非普适法则，而是需根据场景权衡的选择。在代码层面，不可变性有助于理解和测试；在数据建模层面，需要考虑状态模型与事件模型的选择；在API层面，则需根据业务复杂度决定使用Command或Event风格。因此，不可变性应根据具体情况灵活应用。
🎯
关键要点
- 不可变性是指数据创建后不再修改，每次修改产生新版本。
- 不可变性不是普适法则，而是需根据场景权衡的选择。
- 在代码层面，不可变性有助于理解和测试，避免隐藏副作用。
- 并发问题源于共享可变状态，使用不可变对象可以提高安全性。
- 数据层面需要选择状态模型或事件模型，状态模型记录当前状态，事件模型记录历史变更。
- 事件模型存储成本高，设计复杂度大，但在某些场景下有其必要性。
- API层面，Command风格表达意图，Event风格记录事实，选择应根据业务复杂度。
- 不可变性在代码层面强烈推荐，但在数据层和API层需根据具体情况灵活应用。
❓
延伸问答
不可变性在编程中有什么优势？
不可变性有助于理解和测试代码，避免隐藏副作用，提升并发安全性。
在数据建模中，状态模型和事件模型有什么区别？
状态模型只存当前值，而事件模型记录每一笔变更，提供完整的历史信息。
在什么情况下应该使用事件模型？
应在跨系统共享状态、历史有业务价值或需要回溯查询时使用事件模型。
API层面上，Command风格和Event风格有什么不同？
Command风格表达意图，Event风格记录事实，前者请求操作，后者确认发生的事件。
不可变性在代码层面是否总是推荐使用？
在代码层面，不可变性基本上是强烈推荐的，因为代价小而收益大。
使用不可变性有什么潜在的缺点？
使用不可变性可能导致存储成本增加和设计复杂度上升，特别是在数据层和API层。
➡️
