Поясните пожалуйста, как здесь используется оператор new?

Question

[PedroGarciyaLopez]

В документации marionette есть такой пример:

MyApp.addInitializer(function(options){
  new MyAppRouter();
  Backbone.history.start();
});

Не понимаю где в данном случае создается экземпляр MyAppRouter? Т.е. можно ли как-то получить на него ссылку? Если бы он был создан таким образом myApp.myAppRouter = new MyAppRouter(); то был бы доступен как свойство объекта myApp. А как в данном случае?

Comments

[Борис Лапин]

он сохраняет ссылку на себя в нужном ему месте сам, во время инициализации.

[PedroGarciyaLopez]

Борис Лапин: это понятно, получается явно сослаться на этот объект нельзя при таком раскладе?

[Борис Лапин]

index0h ответил на ваш вопрос. Смотрите исходники ) Там узнаете куда записывается экземпляр класса и узнаете, откуда его брать. Кстати, я думаю вам ничто не мешает сделать и как обычно:
inst = new MyAppRouter();
Думаю разработчики таки возвращают ссылку на созданный экземпляр. Просто в данном скрипте он не нужен.

[PedroGarciyaLopez]

Что касается исходников, то ответа на мой вопрос в них нет. MyAppRouter наследуется от Marionette.AppRouter, который в свою очередь наследуется от Backbone.Router, с переопределенным конструктором и дополнительными методами. Безусловно возвращается ссылка на экземпляр и можно сделать как обычно: inst = new MyAppRouter().

Вопрос не столько относится к backbone и marionette сколько вообще к javascript. Я всегда создавал экземпляры вышеописанным способом и не задумывался, а здесь наткнулся и хочу понять. Получается что в каком-то окружении создается объект, он сам может выполнять свои методы, но вызвать их извне и получать свойства этого объекта никак нельзя?

Answer 1

[aen]

Это просто прихоть автора документации. Этот пример взять из документации к Marionette.Application и он демонстрирует работу инициализаторов. Тут ссылка на сам роутер не нужна, потому экземпляр роутера создается таким образом.

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

Answer 2

[dipwoodle]

1. Человек написавший документацию не посчитал нужным, что объект роутера когда-либо понадобится, поэтому не записал в переменную.
2. Экземпляр MyAppRouter создается только в памяти.
3. Доступ к созданному объекту получить нельзя (по крайней мере публично).
4. В данном случае главная логика класса MyAppRouter содержится в конструкторе, поэтому никакой метод этого класса в будущем вызывать не нужно (по задумке автора).
5. А вообще это плохой пример, на практике так делать не хорошо.

Comments

[aen]

А про 5ый пункт можно аргументировать?

[PedroGarciyaLopez]

Да, так и есть. Раньше просто не встречал такого, поэтому был сбит с толку. Но по сути все нормально, объект создается и делает свои дела, без явной ссылки на себя. Вот примерно такая происходит при вызове new: stackoverflow.com/questions/6750880/javascript-how... Если вдруг у кого-то будет подобный вопрос.

Что касается 5го пункта, то мне тоже интересно чем это плохо, кроме того что встречается редко и может смутить таких как я? )

[aen]

PedroGarciyaLopez: в том то и дело, что это ничем не плохо. Если ссылка не нужна, то ее не зачем где-то сохранять.

[PedroGarciyaLopez]

aen: Евгений, с приятным удивлением для себя обнаружил что вы являетесь автором перевода документации: instanceof.pro/marionettejs.ru/.

В первую очередь большое спасибо за труд! Эта тема меня сейчас очень интересует и ваши переводы весьма кстати.

Хотел поинтересоваться, планируется ли перевод, того что еще не переведено, в ближайшее время?

И еще такой вопрос, может быть пожелание. В документации хорошо описаны классы в отдельности, с пониманием проблем нет. Лично у меня, как у новичка, вызывает затруднение именно организация инфраструктуры, взаимодействие компонентов между собой, как из всего этого строить приложение? когда что использовать? С Backbone разобрался достаточно быстро, там-то классов раз-два и обчелся. А здесь только View пять штук, Регионы, Система обмена сообщениями, Рендерер. В общем каша в голове и цельная картинка никак не складывается. Не планируете ли вы готовить материалы способные внести ясность именно в этих вопросах? Или может порекомендуете где посмотреть?

Заранее благодарю.

[aen]

PedroGarciyaLopez: я перевожу по мере того, как у меня есть время. Конечно же я буду переводить все, разве что раздел про Module не буду, так как от него избавятся в ближайшей мажорной версии. После того, как я закончу с документацией, я хочу заняться материалами. У меня есть еще отдельный репозиторий с ними: https://github.com/instanceofpro/awesome-marionette

ПС: если есть желание помочь, то хотя бы вычитайте то, что было переведено. Потому как там есть еще что править. Ну и пуллреквесты приветствуются.

[PedroGarciyaLopez]

aen: Спасибо за ссылку. Откуда такая информация про Module? Нашел книгу Structuring Backbone code with RequireJS and Marionette Modules. И там тема последних затрагивается достаточно обширно.

ПС: Постараюсь помочь, но сначала необходимо въехать в курс дела. Согласитесь, пока нет общей картины, трудно понять, толи перевод не точный, толи сам чего-то не догоняешь.
А на сайте бы не мешало какой-нибудь фидбэк сделать.

[aen]

PedroGarciyaLopez: Это следует из разговоров с мэйнтейнерами. Модули лучше использовать сторонние. ES6, amd или commonjs.

ПС: я имею ввиду, что некоторые предложения написаны "не по-русски" или есть явные орфографические ошибки.

[PedroGarciyaLopez]

aen: Я могу попробовать, но каким образом передавать правки?

[aen]

PedroGarciyaLopez: pull request'ы на гитхабе делайте и все. Или хотя бы issue заводите.

[dipwoodle]

aen: Конечно я бы не хотел показаться слишком категоричным. Просто в ~большинстве случаев~ пихать логику класса в конструктор не верно. SRP знаете ли. На помощь нам всегда приходят метафоры.

Возьмем в качестве примера разработку класса Фонарик. Конструктор - это собственно производство фонарика на заводе. Методы класса - это функциональность фонарика: включить/выключить, заменить батарейку, открутить линзу и тп.

Если мы создаем объект роутера и тут же происходит выполнение байндингов - это не верно. Примерно тоже самое, что на заводе, как только произвели фонарик, так он сразу светит.

Если отвечать на магический вопрос-конструктив "а как надо?", то могу предложить разделить создание объекта роутера и применение байндингов на два этапа:

var myRouter = new MyAppRouter();
myRouter.startListen();

Вариации названия метода могут быть разные: startListen(), start(), run(), listenToHashChange(), bind() и тп.

Почему так делать хорошо?
1. Возможность конфигурации роутера. Добавить роут/удалить роут после того как объект создан.
2. Возможность разделить функции объявления маршрутов и собственно "слушание" маршрутов.
3. Легче тестируется.
4. Следование принципу SRP.
5. ...
Думаю можно найти много преимуществ.

Не имею ничего против Marionette, это наоборот мой любимый сейчас фреймворк, просто данное конкретное решение с роутером недостаточно красиво. Про другие фреймворки вообще молчу :)

[aen]

dipwoodle: ну дак мы тут обсуждаем конкретный пример. Про SRP и SOLID я все прекрасно знаю, не надо мне как нубу все это разжевывать.

Answer 3

[index0h]

Смотрите код MyAppRouter, скорее всего там ответ на ваш вопрос