在JavaScript中使用一个大对象还是多个小对象更好？

我正在编写一个JS库，它可以阅读国际象棋游戏，将它们转换为可重复玩的游戏，在一个网页中可以有许多游戏（一个在自己的div中），我想知道的是——考虑到性能——一个大的对象保存所有游戏的所有动作，还是多个小的对象保存一个游戏的所有动作更好

---

我意识到这可能是整个优化过程中的一个小问题，但这正是我现在想要解决的问题。

不要不必要地担心性能。以一种看起来很自然的方式设计它。显然，您不想将所有游戏的所有动作都放在一个对象中，这违背了面向对象设计的目的。选择第二个选项，每个游戏都有一个对象。除非你在一个页面上加载几千个游戏，否则你不太可能遇到任何问题。

我认为这个问题更多的是关于软件设计，而不是性能。但我很高兴您现在就解决了这个问题，避免了以后的重构

---

我认为你应该把每一个游戏看作是棋盘游戏对象的一个实例（div）。这将有助于开发的其余部分，比如制作自定义的lib和处理游戏的函数，还可以对每个游戏进行线程处理（谷歌为“网络工作者”），提高整体性能。

在我看来，小对象是更好的选择

• 从软件工程的角度来看，使用更小的、可组合的对象进行更模块化的设计比使用一个单一的对象要好得多。我甚至会将每一步都表示为一个对象，而不是每场比赛都有一个对象
• 最近的JS引擎（如V8）尝试从“类”定义构建类似结构的对象。这种情况发生在后台，以便快速访问财产。谷歌对此做出了解释。本质上，如果同一个类的多个小实例或多或少是静态的（也就是说，该类的每个实例都具有相同的属性），V8可以针对这种情况进行优化

Donald Knuth：“我们应该忘记小效率，比如说97%的时间：过早优化是万恶之源”

从领域建模的角度出发，为游戏设计一个正确、自然的数据模型

构建软件

然后，当你处于开发阶段，分析性能是有意义的，找出一些你希望你的游戏在其中工作的低性能环境，并在其中进行测试

你可能会发现你没有问题，正如其他人在回答这个问题时所说的那样

如果发现问题，请分析代码并找出原因。优化您需要的代码。即使您发现性能问题，也不太可能是由您的数据模型引起的，只要您设计得很好

---

如果数据模型真的是一个性能问题，那么只有在达到所需性能的程度上，您才应该对初始设计进行折衷，记录您所做的折衷，以及为什么必须这样做。

利用对象的最佳方法是在JavaScript中使用原型模式。这意味着您与对象共享数据，而不是吝啬地说“那是我的！”

这种模式在JavaScript库中随处可见。它看起来像这样：

var Template = {
  extend: function () {
    var F = function () {};
    F.prototype = this.prototype;
    var instance = new F();
    instance.mixin.apply(instance, arguments);

    return instance;
  },

  mixin: function (mixins) {
    for (var i = 0, len = arguments.length; i < len; i++) {
      for (var k in arguments[i]) if (arguments[i].hasOwnProperty(k)) {
        this[k] = arguments[i][k];
      }
    }

    return this;
  }
};

存储的数据如下所示：

+-------------------.   +---------------------.   +---------.
| Bowser             |->| Koopa                |->| Template |
+--------------------+  +----------------------+  +----------+
|fatalFlaw => 'tail' |  | hasShell => true     |  | mixin    |
 `-------------------+  | fatalFlaw => 'shell' |  | extend   |
                         `---------------------+   `---------+

这个设计源于Crockford神父的设计。正如Knuth所说：“过早优化是万恶之源！”

而且。。。如果这似乎是一个离题的答案，那么这是有意的。您应该询问您的设计如何满足您的需求。如果你做得好，那么一切都会安排妥当。如果你想得不够透彻，你可能会有一些糟糕的副作用和糟糕的代码。帮自己一个忙，想出一个设计，消除任何一点犹豫你。浏览器现在做的事情比解决象棋更复杂，CPU密集

---

所以，我的答案是。。。不要听别人说什么是效率，什么是最好的（甚至是我！）。在图书馆的设计中，做对你最有意义的事情。现在，你想把一个方形的钉子塞进一个圆形的洞里。你需要先决定你的需求是什么，然后一切都会自然而然地发生。这甚至可能会让你大吃一惊

谢谢卡萨布兰卡！它开始于我为一个页面中的一个游戏“设计”，然后意识到可能会有更多，但感谢你和其他人的回答，我知道现在该怎么做了。非常感谢：）谢谢你的提示！我现在很清楚什么是最好的方法：）+10如果可以的话，这是目前为止最好的答案。引用克努特的另一个+1。非常明智：）非常感谢feedback@Marcel：谢谢你的客气话。我发现我自己会周期性地引用这句话，这是一句不断给出的话。我尊重地不同意。虽然这是一个更晚的趋势，但早期优化可以解决很多智能手机技术问题。还有很多只支持JS的应用程序项目（考虑到Yahoo）需要优化到极致。像这个问题这样的问题并不是过度优化，而是优化。对于一种效率低下、内存泄漏严重的语言，就像浏览器使用Javascript一样，这是一个值得关注的问题。@vol7ron:Hmm，事实上，如果不注意性能，你就无法操作。当然有一些项目的性能非常重要，你必须不断地考虑它。然而，这不是其中之一。问题是，很多时候，我们关于什么会表现糟糕的假设只是假设。历史上有很多人因为没有可靠的数据来做出决策而对错误的事情进行了优化。然而，体系结构应该尽早考虑性能。出于无知，我猜这就是智能手机问题的原因

+-------------------.   +---------------------.   +---------.
| Bowser             |->| Koopa                |->| Template |
+--------------------+  +----------------------+  +----------+
|fatalFlaw => 'tail' |  | hasShell => true     |  | mixin    |
 `-------------------+  | fatalFlaw => 'shell' |  | extend   |
                         `---------------------+   `---------+