Questions tagged «immutability»

我看到了使程序中的对象不变的好处。当我真正地为自己的应用程序考虑一个好的设计时，我常常自然而然地想到我的许多对象都是不可变的。我常常想让所有对象保持不变。 这个问题涉及相同的想法，但没有答案表明什么是不变性的好方法以及何时实际使用它。是否有一些好的不变设计模式？总体思路似乎是“使对象不可变，除非您绝对需要更改它们”，这在实践中毫无用处。 我的经验是，不变性将我的代码越来越多地驱动到功能范式，并且这种发展总是会发生： 我开始需要持久性（在功能上）数据结构，例如列表，地图等。 使用交叉引用非常不方便（例如，树节点引用其子节点，而子节点引用其父节点），这使我根本不使用交叉引用，这又使我的数据结构和代码更具功能性。 继承不再有任何意义，我开始改用合成。 OOP的整个基本概念（如封装）开始瓦解，而我的对象开始看起来像函数。 在这一点上，我几乎不再使用OOP范例中的任何内容，而可以切换到纯函数式语言。因此，我的问题是：是否有一种一致的方法来进行良好的不可变OOP设计，或者总是总是这样，当您将不可变的想法发挥到最大潜力时，您总是最终会使用一种功能语言进行编程，而该语言不再需要OOP世界中的任何东西？是否有任何好的指导方针来决定哪些类应该是不可变的，哪些应该保持可变以确保OOP不会崩溃？ 为了方便起见，我将提供一个示例。让我们拥有一个ChessBoard不可变棋子的不可变集合（扩展抽象类）Piece）。从OOP的角度来看，一块负责从板上的位置生成有效的移动。但是要生成移动，棋子需要引用其棋盘，而棋盘需要引用其棋盘。好了，有一些技巧可以根据您的OOP语言创建这些不可变的交叉引用，但是它们很难管理，最好不要用它来引用其董事会。但是由于不知道棋盘的状态，所以棋子无法产生移动。然后，片段变成仅包含片段类型及其位置的数据结构。然后，您可以使用多态函数来生成各种片段的移动。这在函数式编程中是完全可以实现的，但是如果没有运行时类型检查和其他不良的OOP惯例，在OOP中几乎是不可能的...然后，

11 object-oriented  functional-programming  immutability 

我想学习如何在Haskell中制作图并对其执行一些本地操作，但是问题不是特定于Haskell的，我们可以考虑使用双链表来代替图。 问题：用 主要支持和倡导不可变数据结构（Haskell，Clojure等）的语言，惯用或推荐的方式来实现双链表（或其他双链或循环数据结构）及其操作。 ？特别是，如何使用语言正式禁止的就地更新？ 我很容易想到，如果对双向链接列表执行某些本地操作（例如，如果插入了一个项目），由于语言的惰性，可能不需要立即复制整个列表。但是，由于列表是双重链接的，因此如果在一个地方进行修改，则旧节点都不能在列表的新版本中使用，因此，迟早需要对它们进行标记，复制和垃圾收集。显然，如果仅使用列表的更新副本，则这些操作是多余的，但是它们会增加与列表大小成比例的“开销”。 这是否意味着对于此类任务，不可变数据根本不合适，并且对可变数据没有“本地”支持的功能性声明语言不如命令式语言那么好？还是有一些棘手的解决方法？ 附言：我已经在互联网上找到了一些有关该主题的文章和演示，但是很难追踪它们，而我认为这个问题的答案不应该超过一个段落或者是一个图表...我的意思是，如果有对于此问题，没有“功能性”解决方案，答案可能是“使用C”。如果有一个，那么它有多复杂？ 相关问题 “函数式编程中的数据结构”。此处没有讨论我有关使用就地更新而不是效率低下的替代方案的具体问题。 “持久性数据结构的内部变异”。那里的重点似乎是用一种未指定的语言进行的低级实现，而我的问题是关于一种语言（功能语言或其他功能）的正确选择以及功能语言的可能惯用的解决方案。 相关报价 纯粹的函数式编程语言允许非常简洁地表达许多算法，但是在少数算法中，就地可更新状态似乎起着至关重要的作用。对于这些算法，缺乏可更新状态的纯功能语言似乎固有地效率低下（[Ponder，McGeer and Ng，1988]）。 -约翰·劳伯伯里（John Launchbury）和西蒙·佩顿·琼斯（Simon Peyton Jones），《懒惰的功能状态线程》（1994），还有约翰·劳伯伯里和西蒙·佩顿·琼斯，《哈斯克尔州》（1995）。这些论文ST在Haskell中介绍了Monadic类型构造函数。

11 data-structures  functional-programming  graph  immutability 

C＃的一般指导原则是始终在公共领域使用属性。这很有意义-通过公开一个字段，您将公开许多实现细节。通过一个属性，您可以封装该详细信息，从而使其在使用代码中不会被隐藏，并且实现更改与接口更改脱钩。 但是，我想知道在处理readonly关键字时有时是否存在此规则的有效例外。通过将此关键字应用于公共领域，可以额外保证：不变性。这不仅是实现细节，不变性是用户可能感兴趣的东西。使用readonly字段使其成为公共合同的一部分，并且在将来的更改或继承中也不会破坏，而不必修改公共接口。那是财产所不能提供的。 那么，readonly在某些情况下，确保不变性是在属性上选择字段的合法理由吗？ （为澄清起见，我当然不是说您应该总是仅因为该字段恰好是不可变的而做出此选择，只有当该字段作为类设计的一部分是有意义的并且打算将不可变性包括在其合同中时才使用。我最感兴趣的答案是侧重于此是否合理，而不是在某些情况下不合理（例如，当您需要将该成员放在interface或希望进行延迟加载时）。

10 c#  immutability  properties 

我可以看到可变对象与不可变对象（如不可变对象）的好处，消除了由于共享和可写状态而导致的多线程编程中的许多疑难解答问题。相反，可变对象有助于处理对象的身份，而不是每次都创建新的副本，因此特别是对于较大的对象，还可以提高性能和内存使用率。 我想了解的一件事是，在函数式编程的上下文中拥有可变对象可能会出错。像告诉我的要点之一是，以不同顺序调用函数的结果不是确定性的。 我正在寻找一个真正的具体示例，其中很明显在函数编程中使用可变对象会导致什么问题。基本上，如果它不好，那么不管是面向对象还是功能编程范例都不好，对吗？ 我相信，在我自己的发言下面，我可以回答这个问题。但是我仍然需要一些例子，以便我能更自然地感受到。 OO通过诸如封装，多态等工具帮助管理依赖性并编写更容易维护的程序。 函数式编程也具有促进可维护代码的动机，但是通过使用样式消除了使用OO工具和技术的需要-我认为其中之一是通过最小化副作用，纯函数等。

9 c#  object-oriented  programming-practices  functional-programming  immutability 

在先前的问题中，有人告诉我函数式编程语言不适合物理引擎之类的动态系统，这主要是因为变异对象的成本很高。这种说法有多现实？为什么？

9 functional-programming  haskell  clojure  immutability 

我正在开发一个GUI应用程序，该应用程序大量处理图形-为了示例起见，您可以将其视为矢量编辑器。使所有数据结构保持不变是非常诱人的-因此我几乎可以不费吹灰之力就可以撤消/重做，复制/粘贴以及许多其他操作。 为了简单起见，我将使用以下示例-应用程序用于编辑多边形，因此我有“多边形”对象，该对象只是不可变点的列表： Scene -> Polygon -> Point 因此，我的程序中只有一个可变变量-一个保存当前Scene对象的变量。我尝试实现点拖动时就遇到了问题-在可变版本中，我只是抓住一个Point对象并开始修改其坐标。在不可变版本中-我被卡住了。我可以将的索引存储Polygon在current中Scene，将拖动点的索引存储在中Polygon，然后每次替换它。但是这种方法无法扩展-当成分级别达到5时，样板将变得难以忍受。 我确信这个问题可以解决-毕竟，Haskell具有完全不变的结构和IO monad。但是我找不到方法。 你能给我一个提示吗？

9 design-patterns  immutability