使用返回值的函数/方法在变量 VS 中记忆值答案

【问题标题】：memorizing values in variables VS using functions/methods that return values [closed]使用返回值的函数/方法在变量 VS 中记忆值
【发布时间】：2012-01-25 20:42:13
【问题描述】：

我已经在这个问题上徘徊了一段时间了。我还是个初学者，所以我的程序很简单，几乎不需要资源。我熟悉 C++、Java 和 C#。但在未来，事情会变得更加复杂，会有更多的变量和对象以及更多的函数/方法。

为了改变变量的值，我可以调用一个函数/方法来改变值，一次。之后，当我需要变量时，我必须简单地调用它。获得价值所需的时间更少。如果函数做了很多工作，它所消耗的时间只会经历一次。但是变量在内存中需要空间，当它们的数量变得很大时，这可能会成为一个问题。

但是我可以调用一个函数/方法来返回我需要的值。我只需要在必要时使用变量，这意味着更少的变量。如果函数/方法很短，这不是问题。但是有些函数/方法在返回值之前必须做很多工作。这样，用户会觉得程序变慢了。

我的问题是：记忆变量中的值 VS 使用返回值的函数/方法：哪个更好，何时以及为什么？

这个问题听起来像：高速多消耗内存 VS 少消耗内存和低速...

【问题讨论】：

如果您的问题不是特定于语言的，请不要只用您能想到的每个语言标签向它发送垃圾邮件；这不是建设性的。
就我而言，这些是我熟悉的语言。我可以为“非特定语言”添加一个标签（我不记得那个标签的名字了），但很少有人会看到它......
看到它的人可能较少，但至少你的问题不会虚伪，并且会出现在那些真正只想回答特定语言问题的人（比如我自己:-P）。跨度>

标签： c# java c++ function memory

【解决方案1】：

您指出您有时可以用更差的空间效率换取更好的时间效率，当然，反之亦然。

哪个更好？显然，这取决于问题的答案：您的可用空间或时间哪个少？

Bing 需要在几分之一秒内搜索整个互联网；对于 Bing 团队来说，时间非常昂贵，而空间非常便宜，因此他们总是选择节省时间的解决方案，即使这意味着要使用额外的空间。

有些人解决的问题可能会浪费时间，但他们无法在机器中添加更多内存，因为机器在火星轨道上。这些人倾向于优化空间效率而不是时间效率。

根据您的实际情况做出适当的权衡。 在您考虑实际成本之前，没有一种方法明显优于另一种方法。

【讨论】：

我期待一个这样的答案。但是，谢谢！
@Александър Александров 当然。这是正确答案。

【解决方案2】：

避免缓存可以计算的值通常是明智的，因为这样您就可以避免在不同的地方维护状态（如果您最终忘记了会破坏一致性）。

对某个值的计算进行抽象是个好主意（比如将其隐藏在函数后面）。稍后，一旦您的代码工作并且您觉得它很慢，然后使用分析来确定热点。如果这样的函数被证明是热点，你可以在下面引入缓存/记忆，抽象（在理想世界中）将涵盖来自客户端（函数）的令人讨厌的细节。

记忆

记忆一个函数通常涉及一个查找表（基于数组、关联数组等），其键类型是记忆函数的参数的聚合，存储的值是函数的返回值。

然后，该函数将首先检查结果是否已经在查找表中可用并将其返回，或者在返回之前计算并存储它。

事实上，如果编程语言支持这种抽象，这种记忆可以与记忆函数分离，并作为一个单独的层（包装函数）实现。在没有一等函数的语言中，这通常可以使用接口和单方法类来实现。

【讨论】：

旁注：在 C++ 中，执行一些缓慢计算的 const 成员函数可以将结果缓存在可变成员中。然而，这已经很混乱了（嗯，C++）。

【解决方案3】：

将面向对象编程（因为您有 C#、Java 和 C++）作为标签要记住的一点是，类应该具有紧密内聚和松散耦合 .

在你的问题中你说...

但是有些函数/方法在它们之前必须做很多工作返回值

一个紧密结合的类将努力实现一个单一的、集中的目标，并且该类中的其他方法也会效仿。

就可维护性和整体良好的面向对象编程而言，拥有大型方法来执行各种计算以返回值而不是紧密内聚的封装类是不好的做法。

维护一堆返回计算值的大而复杂的方法，而不仅仅是在定义良好的方法中使用私有变量，这可能是开发人员最糟糕的噩梦。

【讨论】：