Singleton .

[Dmitry A. Soshnikov]

И пришел в результате к синглтону

Ну, несомненно, в плане многих проверок - да. Но терминологию "Синглтон" и этот паттерн (при той же организации) можно и не использовать. Например, в плане 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).

[Kolyaj]

Но терминологию "Синглтон" и этот паттерн (при той же организации) можно и не использовать.

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

[Dmitry A. Soshnikov]

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

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

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

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

[Kolyaj]

чем можно оправдать наличие конструктора для одиночного объекта

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

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

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

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

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

[Kolyaj]

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

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

[Dmitry A. Soshnikov]

Это не синглтон

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