我一直在阅读有关不可变数据结构的文章，并了解到变更检测已变得简单。通常，我听说它使应用程序维护更简单，并提供易于理解的编程模型。 我需要帮助才能理解它简化工作的方式。
答案 0 :(得分：5)
Clojure社区已经接受了不变性，这让人大开眼界。我能做的最好的事情是将您发送到来源：Rich Hickey's essay on State和他的谈话The Value of Values。 Rich解释了如何将变量的概念分为三个不同的概念：身份，状态和价值可以帮助您对系统进行建模并对其进行推理。
归结为：在您的编程模型中，如果在您尝试建模的系统中发生变化，您应该只允许更改。否则，您将移动部件（可变变量和对象）添加到不需要它们的模型中。这使得理解模型变得更加困难（特别是随着时间的推移而变化），但很少或没有任何好处。
即使阅读有帮助，唯一可以解决这个问题的方法是使用一种将不变性作为默认值的语言进行编程，直到您意识到您建模的大多数系统实际上只有少数更改的内容而不是页面和页面可变变量。
答案 1 :(得分：1)
在函数式语言中，不变性肯定比在命令式语言中更容易被接受，即使你可以使用限制可变性的Java编程风格（参见this for immutability in Java）。也就是说，我只会评论[功能/不变性]和[对象/可变性]。
我是Clojure粉丝并且发现函数式编程非常强大，但是......
可能是我花了太多时间与C++＆amp; Java而Lisp和Clojure并不够Clojure，但我认为更简单的维护参数尚未被事实证明。我不确定是否有关于大型生产系统的实际维护成本的可靠调查，其中包含所用技术和相关成本的数据。
当然，就LOC而言，像Java这样的语言比{{1}}更加专注和简洁。因此，您可以说较少的代码导致较少的维护，但我认为功能样式提供了非常紧凑的代码，需要非常集中的注意力来完全理解函数正在做什么比较命令式样式，这种样式更冗长但更直接。与不变性相关的函数式编程的一大优势是能够隔离函数并对其进行实验，而无需拖拽卫星对象的大量上下文或构建一堆模拟，这通常是OO语言的情况。抛开实验，纯函数不会修改它的参数，缓解恐惧无意中破坏函数范围之外的某些代码。
但是，撇开功能/不变性优于oop / mutability的优点，在维护方面，我的经验让我觉得技术不是主要问题，而是设计，代码质量和演变代码随着时间的推移，即使最初的代码质量很好。 “好”，我的意思是代码尊重样式约定（如基本命名），管理复杂性，并且在连续（或至少是自动化）构建环境中具有合理的测试工具。
然后，问题变成：是否存在强制更好的设计和更好的代码的范例（功能/不变性，面向对象/可变性）。我的感觉是功能语言是计算机科学热情的土地，OTOH OOP更为主流。是不是因为OOP 更容易才能理解，或者仅仅是教育问题？但是，为了长期维持一个系统，一个人应该选择一个“聪明”的功能环境，很少有人能够解决它，或者一些主流的OO技术 - 不安全或不放心 - 但很多人都有一些知识呢？
当然，解决方案是选择合适的技术（复数）与合适的，有动力的人......