问题标签 [side-effects]

我在函数内部的循环中有一个函数。内部函数在内存中获取并存储大量数据向量（作为全局变量......我使用的是“R”，类似于“S-Plus”）。循环遍历要获取的一长串数据。外部函数启动该过程并传入要获取的数据集列表。

我对内部函数进行了编程，以便在移动到下一个数据集之前存储每个数据集，因此外部函数的所有工作都会作为对全局变量的副作用发生......这是一个很大的禁忌。这比收集和返回一个巨大的、占用大量内存的向量是好还是坏？有没有更好的第三种方法？

如果我将数据向量存储在数据库中而不是内存中，答案会改变吗？理想情况下，我希望能够在不丢失终止之前处理的所有信息的情况下终止该功能（或使其因网络超时而失败）。

我正在学习函数式编程，并试图以函数式风格解决几个问题。在将问题分解为函数时，我经历过的一件事是，我似乎有两个选择：使用具有相似参数列表的几个不同的函数，或者使用嵌套函数，作为闭包，可以简单地引用父函数中的绑定。

虽然我最终选择了第二种方法，因为它使函数调用更小并且似乎“感觉”更好，但从我的阅读来看，我似乎可能错过了函数式编程的要点之一，因为这似乎是“一面-有效”？现在，这些嵌套函数不能修改外部绑定，因为我使用的语言阻止了这一点，但是如果你查看每个单独的内部函数，你不能说“给定相同的参数，这个函数将返回相同的结果”因为他们确实使用了父作用域中的变量......我是对的吗？

什么是理想的进行方式？

谢谢！

我刚刚完成了一个奇怪的 UI 效果的六个小时的调试会话，我发现我最喜欢的框架实现的一个名为“getVisibleRegion”的接口函数禁用了一些 UI 功能（并且显然忘记了恢复它）。

我已经向框架提交了一个错误，但这让我想到了适当的设计：在什么情况下对一个名称暗示仅仅是计算/获取操作的操作产生任何副作用是合法的？

对于那些对实际细节感兴趣的人：我有一个关于我的插件不断破坏 Eclipse 的代码折叠导致折叠栏消失并且无法“展开”或查看折叠代码的错误的报告。我将其追溯到对 ITextViewer 上的 getVisibleRegion() 的调用，该 ITextViewer 的类型表示源代码查看器。现在，ITextViewer 的文档确实声明“实现 ITextViewerExtension5 的查看器可能被迫更改显示的输入文档的部分，以履行此合同”。然而，实际的实现有点过于宽松了，只是永久禁用了投影（折叠），永远不会把它带回来。

我见过这样的方法：

这是修改方法中的参数的好习惯吗？

这不是更好吗？

感觉第一个例子有意想不到的副作用。

我正在开发一个 8051 上的项目，其中每个字节都很重要。因此，我使用了一些我通常不会使用的全局变量。将指针传递给函数的常规方法在这里增加了太多开销。

除了正常的返回值之外，我有许多函数使用单比特变量（编译器特定的C扩展）来表示函数的结果。

鉴于该技术是邪恶的，有什么方法可以使代码更清晰吗？

我应该如何最好地指示哪些函数调用会产生设置这些标志的副作用？评论够吗？我应该命名函数以指示它们的 API（准匈牙利风格）吗？我是否应该使用宏来标记此类调用：

还有其他想法吗？

我觉得这个词有点贬义。因此，我对维基百科中的两句话感到震惊：

命令式编程以使用副作用来使程序运行而闻名。反过来，函数式编程以其最小化副作用而闻名。[1]

由于我有点偏向数学，后者听起来很棒。副作用的论据是什么？它们是意味着失去控制还是接受不确定性？它们是好事吗？

所以我目前正在研究一种新的编程语言。受并发编程和 Haskell 思想的启发，该语言的主要目标之一是管理副作用。或多或少，每个模块都需要指定它允许的副作用。所以，如果我在做游戏，图形模块就没有能力做 IO。输入模块将无法绘制到屏幕上。人工智能模块需要完全纯净。游戏的脚本和插件可以访问非常有限的 IO 子集来读取配置文件。等等。

然而，什么构成副作用并不明确。我正在寻找关于我可能想用我的语言考虑的主题的任何想法或建议。以下是我目前的想法。

一些副作用是明显的。无论是打印到用户控制台还是发射导弹，任何读取或写入用户拥有的文件或与外部硬件交互的操作都是副作用。

其他更微妙，这些是我真正感兴趣的。这些可能是获取随机数、获取系统时间、休眠线程、实现软件事务内存，甚至是非常基本的事情，例如分配内存。

与其他用于控制副作用的语言不同（看看你的 Haskell），我想将我的语言设计为务实和实用的。对副作用的限制应该有两个目的：

• 帮助分离关注点。（没有一个模块可以做所有事情）。
• 对应用程序中的每个模块进行沙箱处理。（任何模块都可以用作插件）

考虑到这一点，我应该如何处理“伪”副作用，如我上面提到的随机数和睡眠？还有什么我可能错过的？我可以通过哪些方式将内存使用和时间作为资源进行管理？

正如我一直理解的那样，对程序状态（或与 IO 相关的任何事情）的任何更改都是副作用。更改是发生在全局变量中还是发生在调用该方法的对象的私有字段中都没有关系。因此，所有不返回任何内容的方法要么什么都不做，要么有副作用。
我的困惑来自我们大学的一位讲师（他仍然是学生，因此还不是无所不知的；））告诉我二传手没有副作用。

我最近一直在玩函数式编程，关于副作用的主题有很好的处理方法，为什么应该包含它们等等。在使用 OOP 的项目中，我正在寻找一些资源来制定一些策略最小化副作用和/或状态。

RESTful Web Services一书就是一个很好的例子，它为您提供了在 Web 应用程序中最小化状态的策略。还有什么其他存在？

请记住，我不是在寻找另一本 OOP 分析师/设计模式书籍（尽管良好的封装和松散耦合有助于避免副作用），而是寻找主题本身就是状态/副作用的资源。

一些编译的答案

• 主要关心状态的 OOP 程序员这样做是因为并发性，因此请阅读Java 并发实践。[正是我想要的]
• 使用 TDD 使副作用更明显[我喜欢它，例如：你的设置越大，运行测试所需的状态就越多 = 好警告]
• 命令查询分离 [好东西，防止更改通常令人困惑的函数参数的副作用]
• 方法只做一件事，如果它们改变了对象的状态，可能会使用描述性的名称，这样简单明了。
• 使对象不可变 [我真的很喜欢这个]
• 将值作为参数传递，而不是将它们存储在成员变量中。[我没有链接这个；它使函数原型变得混乱，并且被 Clean Code 和其他书籍积极劝阻，尽管我承认它有助于解决状态问题]
• 重新计算值而不是存储和更新它们[我也很喜欢这个；在我工作的应用程序中，性能是一个小问题]
• 同样，如果可以避免，请不要复制状态。让一个对象负责保存它，并让其他人在那里访问它。【OOP基本原理，好建议】

我有一个我开始实施的缓存想法：

记忆 function并将返回值与函数签名的哈希一起存储在Velocity中。使用PostSharp，我想检查缓存并返回返回值的重新水化表示，而不是再次调用该函数。我想使用属性来控制这种行为。

不幸的是，这对我组织中的其他开发人员来说可能是危险的，如果他们爱上了性能提升并开始用缓存属性装饰每一个可见的方法，包括一些带有副作用的方法。当记忆库怀疑某个函数可能会导致副作用时，我想退出编译器警告。

使用 CodeDom 或 Reflection 如何判断代码可能会导致副作用？