Singleton .
 

Отвечу тут Дмитрию, на хабре дискутировать неудобно.

Singleton'у может понадобиться конструктор, который желательно вызвать в момент первого использования объекта. Тогда простой объект будет использовать неудобно.

Я вот здесь в конце статьи привел вариант реализации Singleton, но, честно говоря, сам им пока не пользовался :)

Да, спасибо, я уже читал эту статью.

На самом деле, если экземпляр не понадобится, то мы и не создадим этот объект. В твоём варианте, если экземпляр понадобится, будет создан и объект, и конструктор.

В качестве преимущества, можно выделить хранение в контексте конструктора каких-то вспомогательных "скрытых" сущностей (которые могут быть использованы в методах объекта), но тот же результат можно получить простым созданием контекста из FE, которая уничтожится сразу после инициализации объекта.

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

В обычном варианте var S = {} он создастся в любом случае.

Да, и это означает, что он нужен. Если не нужен - не создаётся (т.е. его нет в коде).

Kolyaj, там же, на Хабре, приводят преимуществом наследование, с этим - согласен.

var S = {...};
if (...) {
    // Здесь S нужен
} else {
    // А здесь не нужен
}

В моем варианте с наследованием туго :)

Ну, всё правильно (даже, если динамически, по условию):

if (...) {
  var S = {};
} else {
  ...
}

В любом случае (и в твоей реализации тоже), переменная "S" уже будет в объекте переменных.

Ещё преимуществом можно выделить частые подобные проверки с if-ми-else-ами. Чтобы каждый раз не проверять, инициализирован ли уже объект (if typeof S !== 'undefined'), можно вынести его в геттер (который и называется в данном случае "Singleton"):

function getOurObject() {
  if (!arguments.callee.instance) {
    arguments.callee.instance = {...};
  }
  return arguments.callee.instance;
}

В общем, два преимущества:

1. Наследование (если нужно);
2. Улучшение code-reuse, чтобы сократить код (этот пункт, в данном случае, является разновидностью memoization).

А если несколько таких if'ов?

Переменная будет, но значения-то у нее не будет.

Да, я это отметил:
Ну так и в простом случае (var S = {}) так же, разницы нет здесь.

И пришел в результате к синглтону, про который сказал в начале :)

Ну, несомненно, в плане многих проверок - да. Но терминологию "Синглтон" и этот паттерн (при той же организации) можно и не использовать. Например, в плане Java-Swing-a или JavaScript-ового Ext-фреймворка (который вдохновлён Swing-ом) можно повсеместно видеть код:

getPanel: function () {
  if (!this.panel) {
    // вычисления и создание панели
  }
  return this.panel;
}

// и потом в 10 методах
// this.getPanel()

Я говорил об _этом_, когда упомянул разновидность memoization. Здесь ближе по _идеологии_ именно к этой сущности, но не к Singleton. Хотя, в определении "возвращает один и тот же объект" - да, можно и терминологию "Singleton" приплести. Если же это ещё подкрепить и оператором new, то вообще ещё больше похоже (но сути не меняет).

А это в плане, когда нужен просто объект и известно, что он, действительно, будет нужен.

В этом случае, смысла в дополнительном конструкторе нет. Более того, в том же Ext-e, например, люди пишут, опять же, в Java-Swing-стиле: именно для организации наследования создают наследника от какого-то базового "класса", даже, если затем этот наследник породит всего _один_ объект. Спрашивается, зачем конструктор? Для наследования. Из-за этого приходится его плодить. Если бы можно было по стандарту (а не только через __proto__ в конкретных реализациях) менять свободно прототип, то пункт с наследованием бы отпал, конструктор был бы не нужен (как, кстати, и new).

Ну не придумывать же новый термин.

Да нет же, вот пример с геттером для this.panel из примера выше - разве ты это называешь "Синглтоном"? Технически-то понятно, что и там (паттерн "Синглтон"), и там (memoization, кэш) - возвращается один объект, но идеология-то разная.

Повторю, в ответе на Хабре имелся в виду обычный объект, который однозначно будет использоваться (и в этом плане, конструктор - лишний). Более того, если уж приплетать терминологию "Синглтон", можно и этот объект назвать "Синглтоном" (а чем он отличается от того, который будет порождён альтернативным конструктором?).

Но, опять повторюсь, чем можно оправдать наличие конструктора для одиночного объекта - это (1) наследование (и, как пример, я привожу идеологию ExtJS и её обёртку наследования - когда для одной панели нужно объявить "класс") и (2) - геттер для частых проверок.

В моем случае цели декоративные.

var S = {
// много строк кода
};

// А вот тут уже инициализация объекта

Такой код читается хуже, чем

var S = Singleton({ // <-- псевдокод
    init: function() {
        // инициализация
    },
    // остальной код
})

Это не синглтон, для разных объектов панель будет разная.

Так в вопросе о множественных проверках (if-aх, else-ах), я о чём и говорю - это можно не называть "Синглтоном". Это геттер, который, одним из действий, выполняет инициализацию.