Цитата:
|
В этом примере не стоит. Если вы приведете другой, тогда можно о нём и поговорить.
|
Естественно данные подходы не нужны для того чтобы спрятать одну функцию. Естественно, что они используются, когда возникает возможность совпадения имен, т.е. при большом количестве скрипта.
На счет стоит-не стоит - пока ни единого разры... тьфу обоснования кроме личных предрасположенностей не встретил. Мне так нравится писать, на мой вгляд если функция не нужна вне, то во вне её быть не должно. Читаемость кода от этого не страдает совсем. Даже наоборот! Есть реальная разница в скорости? Ну или хотябы возможность это проверить? Цитата:
Получается во втором случае инфа хранится дважды? |
есть замечательный скрипт для дампа объекта в целях отладки:
function dump( obj ){ var pairs= []; var blocked= []; if( obj ) for( var key in obj ){ try{ pairs.push( key + ': ' + obj[ key ] ); } catch( e ){ blocked.push( key ); } } if( pairs ) obj+= ' {', pairs.join(', '), '}'; if( blocked ) obj+= '[blocked: ' + blocked.join(', ') + ' ]'; return obj; } так вот, сокрытие переменных приводит к тому, что мы не можем полноценно отлаживать приложение, ибо не можем получить полное состояние объекта. |
>Естественно, что они используются, когда возникает возможность совпадения имен
Совпадение имён здесь совершенно никаким боком. >Есть реальная разница в скорости? Ну или хотябы возможность это проверить? Да. Описать эту возможность? >обоснования кроме личных предрасположенностей не встретил. Обоснования были даны совершенно чёткие - страдает читабельность кода, скорость скрипта, количество используемой памяти. Замыкания позволяют создать аналог скрытых свойств и перенос напрямую всех подходов из "классового" ООП обычно не приводят ни к чему хорошему. |
Я тоже считаю, что если в JavaScript нету встроенного разделения на private/public, то изворачиваться через закрытие области видимости - кощунство.
Я, например, не могу подобрать задачу, в которой нужно будет скрыть определённые свойства объекта. Обычно это делается либо для защиты (закрытие кода/состояния от внешнего доступа), что актуально в коде "библиотек", либо просто для эстетики, чтоб внутренние действия класса не были наглядны и не мешали пониманию работы. Но если эстетика представления объекта мешает эстетики кода JavaScript, то лучше, всё-таки, на ней не зацикливаться. |
> Извиняюсь, не совсем понял, во втором случае у нас еще остается анонимная функция,
Да. Еще раз: первый подход вполне уместен (и именно для обеспечения того, чтобы не засорять глобальный объект), когда речь идет об инициализации, и внутри этой инициализации используются вспомогательные локальные var'ы. Скоп этой "singleton'ной" функции будет доступен внутренним замыканиям и, как следствие, свойствам иницализируемого объекта. Но в отличии от второго случая, функция не будет жить дальше (во втором - будет - и зачем это надо? Поэтому первый способ - предпочтительней). Цитата:
|
А где в примере из первого поста singleton? В моём преставлении этот паттерн реализуется в виде метода, возвращающего ссылку на экземпляр класса. Или я не прав? Хотя зачем такое в JavaScript, тут вообще классов по сути нету.
|
такой подход не может быть уместен, ибо все методы создаются заново при каждом инстанцировании объекта.
|
Цитата:
Скорость определения замкнутых var'ов, естественно, будет медленнее, т.к. они находятся не в родном скопе (в смысле, return this.a будет быстрее, чем return a, где a - локальный замкнутый var). А подобие (имитация) классического паттерна могла бы выглядеть, например, так: function SingletonClass() { } SingletonClass.getInstance = function() { if (!SingletonClass.instance) { SingletonClass.instance = new function() { this.a = 10; return true; }; SingletonClass.instance.getA = function() { return this.a; }; SingletonClass.instance.setA = function(a) { this.a = a; return true; }; } return SingletonClass.instance; }; var a = SingletonClass.getInstance(); a.setA(20); var b = SingletonClass.getInstance(); alert(b.getA()); |
Часовой пояс GMT +3, время: 14:35. |