bubuq Apr 8 2011 at 17:23

Модульный подход в JavaScript

8 min

49K

JavaScript*

Translation

+109

Comments 32

Autorun Apr 8 2011 at 17:54

Давно хотелось почитать нечто подобное.

Dmitris Apr 8 2011 at 18:46

наконец то я понял назначение замыканий в js :) спасибо за перевод и ссылку!

k12th Apr 8 2011 at 18:47

Далеко не все можно описать этими анонимными замыканиями. Не везде они удобны.

var MODULE = (function (my) { 
    my.anotherMethod = function () { 
        // added method... 
    }; 
 
    return my; 
}(MODULE));

Мне кажется, что проще так:

var MODULE = (function (my) { 
    this.anotherMethod = function () { 
        // added method... 
    }; 
 
    return my; 
}).call(MODULE);

Autorun Apr 8 2011 at 19:07

В чем преимущества вашей альтернативы?

k12th Apr 8 2011 at 19:21

Чисто визуально мне лично так больше понятно, что происходит.

Ну и правильнее как-то создавать отдельный контекст (ну или использовать существующий) — потому что в исходном варианте this — это window (точнее, глобальный объект).

Pozadi Apr 8 2011 at 19:24

Вы хотели написать:

var MODULE = (function () {
this.anotherMethod = function () {
// added method…
};

return this;
}).call(MODULE);

?

k12th Apr 8 2011 at 19:25

Ох, да, конечно.

TheShock Apr 8 2011 at 22:19

var MODULE = new function () {
    this.anotherMethod = function () {
        // added method...
    };

    return this;
};

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

TheShock Apr 8 2011 at 22:20

Хотя можно даже так:

var MODULE = new function () {
    this.anotherMethod = function () {
        // added method...
    };
};

tenshi Apr 9 2011 at 01:29

var MODULE = new function () {
Object( MODULE ).constructor.apply( this )
this.anotherMethod = function () {
// added method…
};
};

UFO landed and left these words here

k12th Apr 9 2011 at 00:15

А я и не говорил, что я в восторге. Но так иногда делают, и я иногда так делаю, когда это кажется уместным.
Я всего лишь сделал более явным тот факт, что происходит расширение объекта.

Да и вообще — будь это готовый фреймворк, было бы клево, а так — просто подход.

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

TheShock Apr 9 2011 at 00:55

Я не делаю вам замечание. Просто дополнил)

k12th Apr 9 2011 at 00:57

Аналогично:)

UFO landed and left these words here

kashey Apr 8 2011 at 18:50

Самое хитрое в модульном подходе это моменты модульной сборки и возможности в модуле определять различные классы работающие именно в пространстве данного модуля( что тянет за собой различные implements\provide\register\require и другие exports).
А описание переменой в локальном замыкании — это разве модульность?

AndrewStephanoff Apr 8 2011 at 18:51

Вообще YUI3 занятная штука, крайне рекомендую

azproduction Apr 8 2011 at 19:33

Я больше предпочитаю «активный» экспорт. Потому, что он больше вяжется с CommonJS Modules и отлично подходит как для Node.js так и для браузера.

(function (exports/* остальные объекты и алиасы по вкусу */) {
    var MyObject = {};

    exports.MyObject = MyObject;
}(typeof exports === 'undefined' ? window : exports));

// Если надо расширить, то
(function (MyObject) {
    MyObject.smth = function () {};
}(typeof require === 'undefined' ? MyObject : require('MyObject'));

Если использовать такой вид модуля, не экспортировать в глобалы и написать хороший сборщик (1 .js файл), то мы можем избавить window от лишних глобальных объектов, что является самой сложной техникой JavaScript Ninja ;)

k12th Apr 8 2011 at 21:05

Мне нравится ваше кунг-фу:)

GeniyZ Apr 8 2011 at 23:49

может отдельную статью запостишь по этому поводу?
возможно не до конца понял, но видимо это самый верный путь.
поделишься подходом в развёрнутом виде??

tyro Apr 10 2011 at 10:05

CommonJS modules это вещь. Если хотите поэксперементировать с ними, советую попробовать прямо из браузера на Akshelle

tenshi Apr 10 2011 at 13:07

ага, вещь. из-за их баловства с эвалом фиг найдёшь место ошибки.
а в акшелле нет банальной консоли ошибок, из-за чего полезность всех их свистелок стремится к нулю.

tyro Apr 10 2011 at 13:30

С каким эвалом? Он вообще здесь ни причем.

А в акшеле stack trace видно в HTML в Preview и в Eval консоле тоже. Добавь строку 'throw new Error();' и убедись сам(а).

tenshi Apr 11 2011 at 02:34

docs.google.com/present/view?hl=en&id=dcd8d5dk_0cs639jg8 9 слайд

днём не выводил. хотя, может я писал просто throw 123, не помню уже.

tyro Apr 11 2011 at 13:26

Ну это только в их имплементации, вообще-то эвал в других местах не используется для этого.

powerman Apr 9 2011 at 04:55

Никогда не понимал, зачем тащить всякие private/protected из языков вроде Java в динамические языки вроде JavaScript или Perl. Да, с помощью клозур и такой-то матери можно что-то спрятать, но нафига это нужно?! Если кто-то захочет залезть внутрь и отстреляться себе по ногам — всё-равно залезет и отстреляется, так или иначе. А потом начинают изобретать извращения чтобы добраться к тому, к чему сами себе закрыли доступ.

Практика показывает, что для разделения на public и private более чем достаточно соглашения об именах: private методы и свойства начинаются на подчёркивание. Этого более чем достаточно, чтобы сохранить наглядность интерфейса, и чтобы легко обнаруживать нарушения инкапсуляции во время code review (а то и автоматически, просто запустив grep по исходникам).

vanxant Apr 9 2011 at 05:48

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

powerman Apr 9 2011 at 14:12

Не отрицаю. Но я об этом ничего и не говорил. Просто я для реализации модулей предпочитаю более нативный подход через prototype, а не клозуры:


var MODULE = function(){
    this.public = 'some';
    this._private = 'some';
};

MODULE.prototype.public_method = function(){
   this._private_method();
};

MODULE.prototype._private_method = function(){
   …
};

obj = new MODULE();

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

tenshi Apr 9 2011 at 12:34

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

powerman Apr 9 2011 at 13:55

Я стараюсь не злоупотреблять наследованием. Даже, я бы сказал, не употреблять вообще. :) Это сильно упрощает жизнь.

А в тех редких случаях, когда наследование действительно удобно — как правило либо классы родителя и потомков пишутся одним разработчиком, контролирующим такие конфликты, либо в потомке для гарантии отсутствия конфликтов его личные приватные свойства и методы содержат префикс — имя потомка. Да, удобным и элегантным подходом это никак не назовёшь, и при активном использовании наследования описанные в статье подходы будут предпочтительнее. Но если наследование используется в качестве исключения, а не правила, то этих простых подходов более чем достаточно.

Foror Apr 9 2011 at 09:58

Спасибо за статью, давно хотел разобраться как проще всего организовать модули на JavaScript без внешних библиотек.