我一直在阅读关于Immutable数据结构的文章，了解到它可以使变更检测更容易。而且很常听到它可以简化应用程序的维护，并提供易于理解的编程模型。 我需要帮助理解它是如何简化工作的。
2个回答
5
Clojure社区已经接受了不变性，这是一个启发。我能做的最好的事情就是把你带到源头：Rich Hickey关于状态的论文和他的演讲价值的价值。 Rich解释了如何将变量的概念分成三个不同的概念：标识，状态和价值，以帮助您建模和推理系统。
简而言之：在编程模型中，只有在您试图建模的系统中才允许更改事物。否则，您会向不需要它们的模型中添加移动部件（可变变量和对象）。这使得理解模型更加困难（特别是随着时间的推移），但几乎没有任何好处。
即使阅读有所帮助，但理解这一点的唯一方法就是使用将不变性作为默认选项的语言进行编程，直到您意识到您建模的大多数系统实际上只有少量的变化，而不是页页可变变量。
简而言之：在编程模型中，只有在您试图建模的系统中才允许更改事物。否则，您会向不需要它们的模型中添加移动部件（可变变量和对象）。这使得理解模型更加困难（特别是随着时间的推移），但几乎没有任何好处。
即使阅读有所帮助，但理解这一点的唯一方法就是使用将不变性作为默认选项的语言进行编程，直到您意识到您建模的大多数系统实际上只有少量的变化，而不是页页可变变量。
- sbensu
1
不可变性在函数式语言中比命令式语言更受欢迎，即使你可以采用限制可变性的Java编程风格（参见this for immutability in Java）。话虽如此，我只会评论[函数式/不可变性]和[面向对象/可变性]。
我是Clojure的粉丝，发现函数式编程真的很强大，但是...
也许我花太多时间在C++和Java上，没有花足够的时间在Lisp和Clojure上，但我认为“更简单的维护”论点尚未被事实证明。我不确定是否有关于实际生产系统维护成本的可靠调查，其中包括所使用的技术和相关成本的数据。
当涉及到LOC时，像Clojure这样的语言比Java更加专注和简洁。因此，可以说更少的代码会导致更少的维护工作，但我认为函数式风格提供了更紧凑的代码，需要非常专注的注意力才能完全理解函数在做什么，而命令式风格则更冗长但有点直截了当。函数式编程与不变性相关的一个重要优势是能够隔离一个函数并对其进行实验，而无需拖动一大堆卫星对象的繁重上下文或构建一堆模拟，这在面向对象的语言中经常发生。撇开实验不谈，纯函数不会修改其参数，这使得人们不必担心意外破坏函数范围外的某些代码片段。
但是，撇开函数/不可变性对oop/可变性的优点不谈，在维护方面，我的经验让我认为问题不在于技术，而在于设计、代码质量以及即使最初的代码质量良好，随着时间的推移它的演化。所谓“良好”，指的是代码尊重样式惯例（如基本命名）、管理复杂性，并具有合理的测试框架，在持续（或至少自动化）构建环境中。
那么问题就变成了：是否有一种范式（函数式/不可变性，面向对象/可变性）可以强制实现更好的设计和更好的代码。我的感觉是，函数式语言是计算机科学爱好者的乐园，而OOP则更加主流。这难道不是因为OOP更容易理解，还是仅仅是教育问题？但是，为了长期维护系统，应该选择一个“聪明”的功能环境，只有少数人能够处理它，还是一些主流的OO技术——虽然存在不安全或过于宽松的问题——但很多人都有一定的知识呢？
当然，解决方案是选择正确的技术（复数）和正确的、有动力的人...
我是Clojure的粉丝，发现函数式编程真的很强大，但是...
也许我花太多时间在C++和Java上，没有花足够的时间在Lisp和Clojure上，但我认为“更简单的维护”论点尚未被事实证明。我不确定是否有关于实际生产系统维护成本的可靠调查，其中包括所使用的技术和相关成本的数据。
当涉及到LOC时，像Clojure这样的语言比Java更加专注和简洁。因此，可以说更少的代码会导致更少的维护工作，但我认为函数式风格提供了更紧凑的代码，需要非常专注的注意力才能完全理解函数在做什么，而命令式风格则更冗长但有点直截了当。函数式编程与不变性相关的一个重要优势是能够隔离一个函数并对其进行实验，而无需拖动一大堆卫星对象的繁重上下文或构建一堆模拟，这在面向对象的语言中经常发生。撇开实验不谈，纯函数不会修改其参数，这使得人们不必担心意外破坏函数范围外的某些代码片段。
但是，撇开函数/不可变性对oop/可变性的优点不谈，在维护方面，我的经验让我认为问题不在于技术，而在于设计、代码质量以及即使最初的代码质量良好，随着时间的推移它的演化。所谓“良好”，指的是代码尊重样式惯例（如基本命名）、管理复杂性，并具有合理的测试框架，在持续（或至少自动化）构建环境中。
那么问题就变成了：是否有一种范式（函数式/不可变性，面向对象/可变性）可以强制实现更好的设计和更好的代码。我的感觉是，函数式语言是计算机科学爱好者的乐园，而OOP则更加主流。这难道不是因为OOP更容易理解，还是仅仅是教育问题？但是，为了长期维护系统，应该选择一个“聪明”的功能环境，只有少数人能够处理它，还是一些主流的OO技术——虽然存在不安全或过于宽松的问题——但很多人都有一定的知识呢？
当然，解决方案是选择正确的技术（复数）和正确的、有动力的人...
- T.Gounelle
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接