Лучше ли иметь один большой объект в JavaScript или многие более мелкие?

Ответ 1

Дональд Кнут: "Мы должны забыть о небольшой эффективности, скажем, около 97% времени: преждевременная оптимизация - корень всех злых"

Начните с разработки модели данных для вашей игры, которая является правильной и естественной с точки зрения моделирования домена.

Создайте программное обеспечение.

Затем, когда вы находитесь на этапе разработки, который анализирует производительность, имеет смысл, выработайте несколько низкопроизводительных сред, в которых вы хотите, чтобы ваша игра работала, и протестируйте их.

Вероятно, вы обнаружите, что у вас нет проблем, как говорили другие в ответах на этот вопрос.

Если вы обнаружите проблему, прокомментируйте свой код и узнайте причину. Оптимизируйте код, который вам нужен. Даже если вы обнаружите проблему с производительностью, она вряд ли будет вызвана вашей моделью данных, если вы ее хорошо разработали.

Если модель данных действительно является проблемой производительности, только тогда вы должны поставить под угрозу свой первоначальный дизайн только в той степени, в которой вы нуждаетесь, чтобы получить требуемую производительность, документируя достигнутые вами компромиссы и почему вы должны были.

Ответ 2

Лучшим способом использования объектов является использование прототипа в 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;
  }
};

Этот магический класс будет обмениваться данными по цепочкам наследования и упростить вашу объектную модель. Ничего классного - все Объект! Это означает понимание мелочей JavaScript, чтобы не застревать в липком слизе, но это того стоит.

Это означает, что когда у вас есть:

var Koopa = Template.extend({
  hasShell: true,
  fatalFlaw: 'shell'
});

var Bowser = Koopa.extend({
  fatalFlaw: 'tail'
});

Сохраненные данные выглядят следующим образом:

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

Этот дизайн проистекает из дизайна прототипа наследования отца Крокфорда . И, как говорит Кнут, "преждевременная оптимизация - это корень всего зла!"

И... если это похоже на ответ от темы - оно предназначено. Вы должны задавать вопросы о том, как ваш дизайн может удовлетворить ваши потребности. Если вы сделаете это хорошо, тогда все должно встать на свои места. Если вы не думаете об этом достаточно, вы можете получить некоторые неприятные побочные эффекты и вонючий код. Сделайте себе одолжение и придумайте дизайн, который избавит вас от любых колебаний. В эти дни браузеры усложняют работу с процессорами, а не решают шахматы!

Итак, мой ответ: не слушайте, что говорят люди об эффективности, или о том, что лучше всего (даже я!). Сделайте то, что имеет для вас наибольшее значение, в дизайне вашей библиотеки. Прямо сейчас, вы пытаетесь засунуть квадратный штифт в круглое отверстие. Вам нужно сначала решить, каковы ваши потребности, и после этого все будет естественным. Это может даже удивить вас!

Ответ 3

Маленькие объекты - предпочтительный выбор в моих глазах.

• С точки зрения разработки программного обеспечения гораздо лучше иметь более модульный дизайн с меньшими, сложными объектами, а не с одним монолитным объектом. Вместо того, чтобы иметь один объект за игру, я бы даже представлял каждое движение как объект.
• Последние JS-движки, такие как V8, пытаются построить объекты типа struct из "классов". Это происходит за кулисами для быстрого доступа к объектам. Google объясняет это в дизайне V8. По сути, если у вас несколько небольших экземпляров того же класса, которые более или менее статичны (т.е. Каждый экземпляр класса имеет те же свойства), V8 может оптимизировать для этого случая.

Ответ 4

Не беспокойтесь о производительности. Создайте его таким образом, который кажется естественным. Очевидно, вы не хотите, чтобы все ходы всех игр были объединены в один объект, который побеждает цель объектно-ориентированного дизайна. Пойдите со вторым вариантом и получите объект для каждой игры. Очень маловероятно, что у вас возникнут проблемы, если вы не загрузите несколько тысяч игр на одной странице.

Ответ 5

Я думаю, что этот вопрос гораздо больше касается дизайна программного обеспечения, чем производительности. Но я рад, что вы обращаетесь к нему сейчас, избегая повторного реорганизации позже.

Я думаю, вы должны думать, что каждая игра является экземпляром (div) объекта ChessGame. Это облегчит большую часть остальной части разработки, как создание пользовательских функций и функций для работы с игрой, также у вас будет возможность нарезать каждую игру (google для "веб-работников" ), увеличивая общую производительность.