aen: Конечно я бы не хотел показаться слишком категоричным. Просто в ~большинстве случаев~ пихать логику класса в конструктор не верно. SRP знаете ли. На помощь нам всегда приходят метафоры.
Возьмем в качестве примера разработку класса Фонарик. Конструктор - это собственно производство фонарика на заводе. Методы класса - это функциональность фонарика: включить/выключить, заменить батарейку, открутить линзу и тп.
Если мы создаем объект роутера и тут же происходит выполнение байндингов - это не верно. Примерно тоже самое, что на заводе, как только произвели фонарик, так он сразу светит.
Если отвечать на магический вопрос-конструктив "а как надо?", то могу предложить разделить создание объекта роутера и применение байндингов на два этапа:
var myRouter = new MyAppRouter();
myRouter.startListen();
Вариации названия метода могут быть разные: startListen(), start(), run(), listenToHashChange(), bind() и тп.
Почему так делать хорошо?
1. Возможность конфигурации роутера. Добавить роут/удалить роут после того как объект создан.
2. Возможность разделить функции объявления маршрутов и собственно "слушание" маршрутов.
3. Легче тестируется.
4. Следование принципу SRP.
5. ...
Думаю можно найти много преимуществ.
Не имею ничего против Marionette, это наоборот мой любимый сейчас фреймворк, просто данное конкретное решение с роутером недостаточно красиво. Про другие фреймворки вообще молчу :)
1. Не вижу предпосылок к изменению дат, скорее всего меняться и добавляться не будут.
2. Второй вариант.
3. Легко рефакторится. Создается отдельный модуль DateUtil, тело хелперов копируется в функции, в хелперах вызываются функции DateUtil.
Поддерживаю вариант 2, как более быстрый и простой. Спасибо!
Назвать метод для второго типа дат думаю как "standardDateForma()" или "globalDateFormat()". Это должно натолкнуть человека на мысль, что этот формат используется везде по всей системе
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Возьмем в качестве примера разработку класса Фонарик. Конструктор - это собственно производство фонарика на заводе. Методы класса - это функциональность фонарика: включить/выключить, заменить батарейку, открутить линзу и тп.
Если мы создаем объект роутера и тут же происходит выполнение байндингов - это не верно. Примерно тоже самое, что на заводе, как только произвели фонарик, так он сразу светит.
Если отвечать на магический вопрос-конструктив "а как надо?", то могу предложить разделить создание объекта роутера и применение байндингов на два этапа:
var myRouter = new MyAppRouter();
myRouter.startListen();
Вариации названия метода могут быть разные: startListen(), start(), run(), listenToHashChange(), bind() и тп.
Почему так делать хорошо?
1. Возможность конфигурации роутера. Добавить роут/удалить роут после того как объект создан.
2. Возможность разделить функции объявления маршрутов и собственно "слушание" маршрутов.
3. Легче тестируется.
4. Следование принципу SRP.
5. ...
Думаю можно найти много преимуществ.
Не имею ничего против Marionette, это наоборот мой любимый сейчас фреймворк, просто данное конкретное решение с роутером недостаточно красиво. Про другие фреймворки вообще молчу :)