Важность шаблонов проектирования с использованием Javascript, NodeJs и др.

В течение следующих нескольких лет Javascript станет повсеместно распространенным языком веб-программирования, и каждые пять минут появляются новые фреймворки, а программирование, управляемое событиями, становится лидером как на стороне сервера, так и на стороне клиента:

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

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

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

Классические шаблоны проектирования не применимы к JavaScript.

Что применимо, так это написание модульного и функционального кода.

Вы должны использовать смесь конструкторов и функций первого класса.

Как разработчик JavaScript, я лично стремлюсь рассматривать JavaScript как LISP, а не как Java. Поэтому старайтесь эмулировать монады и высокоуровневый код функционального стиля, а не пытаться эмулировать классический ООП-код.

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

Опять же, шаблоны проектирования на самом деле не применяются так сильно, но ниже приведены три важных конструкции.

1. Использование затворов
2. Использование первоклассных функций
3. Использование объектов фабрики с или без new

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

Давайте рассмотрим некоторые классические шаблоны проектирования и способы их реализации в js, а также альтернативные шаблоны, более подходящие для самого js:

Шаблон наблюдателя:

В node.jsэтом все просто events.EventEmitter. В jQueryэтом $.fn.bind&& $.fn.trigger. В backboneэтом есть Backbone.Events.triggerи Backbone.Events.bind. Это очень распространенный шаблон, используемый в повседневном коде.

Я никогда не останавливаюсь и думаю: «Эй, я использую здесь схему наблюдателя!». Нет, это просто низкоуровневый способ передачи сообщений или способ каскадного изменения.

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

В WebSocketпротоколе мы .onиспользуем его для привязки к on("message", ...событиям. Опять же, это очень часто, но это наблюдатель в потоке, а не классическая ООП while (byte b = Stream.ReadNextByte()).

Все это мощное использование шаблона Observer. Но это не шаблон, который вы используете. Это простая часть языка. Это всего лишь код.

Памятная картина:

Это просто JSON. Это позволяет вам сериализовать состояние объекта, чтобы вы могли отменить действие.

function SomeObject() {
    var internalState;

    this.toJSON = function() {
        return internalState;
    }

    this.set = function(data) {
        internalState = data;
    }

    this.restore = function(json) {
        internalState = JSON.parse(json);
    }
}

var o = new SomeObject();
o.set("foo"); // foo
var memento = JSON.stringify(o);
o.set("bar"); // bar
o.restore(memento);

В JavaScript мы изначально поддерживаем API для сувениров. Просто определите метод, вызываемый toJSONдля любого объекта. Когда вы вызываете, JSON.stringifyон будет внутренне вызывать .toJSONваш объект, чтобы получить реальные данные, которые вы хотите сериализовать в JSON.

Это позволяет вам тривиально делать снимки вашего кода.

Опять же, я не понимаю, это образец сувенира. Это просто с помощью инструмента сериализации, который является JSON.

Шаблон состояния / Шаблон стратегии:

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

Примите этот ответ как субъективное мнение.

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

Если вы имеете в виду традиционные шаблоны проектирования, такие как « Бригада четырех» , то большинство методов не зависят от языка / платформы, таких как «Программа для интерфейса, а не реализация» или «Сочетание объектов по наследованию классов» и одинаково важны также для разработчиков JavaScript.

Более специфические паттерны, такие как творческий, структурный и поведенческий, могут или не должны использоваться так же или так же часто, как в других языках, потому что языковые функции могут в значительной степени влиять на их использование. Поэтому некоторые языки (включая JavaScript) имеют свои собственные шаблоны проектирования, основанные на функциональности или синтаксическом сахаре, которые они предлагают.

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

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

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

1. Конструктор шаблон (с прототипами)

Особенно на стороне сервера при написании материала для node.js, потому что он хорошо подходит для написания модулей, хотя в нем отсутствует встроенная инкапсуляция. Также это популярно для многих других разработчиков, если вы просматриваете репозитории на GitHub, поэтому знакомство с этим шаблоном может помочь вам лучше понять другие коды.

2. Выявление шаблона модуля

Предлагает модульность с инкапсуляцией.

3. СУХОЙ Узор

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

Шаблоны проектирования преподаются в классах дизайна для CS. Они не важны, но действительно полезны, если вы можете найти аналогичные ситуации, чтобы найти решение, которое было продумано.

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

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

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

Считаете ли вы, как разработчик Javascript, традиционные шаблоны проектирования важными или менее важными?

Они жизненно важны.

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

Разработчики с любого языка могут изучать продвинутый JS по шаблонам, а не по синтаксису. Те, кто этого не знает, пропускают.

Назовите три основных шаблона дизайна, которые вы регулярно используете в качестве разработчика Javascript.

Существуют часто используемые шаблоны, против которых некоторые «спорят». Тем не менее, их полезно знать, потому что они чрезвычайно распространены и мощны в продвинутом JS.

1- Пространство имен - оберните ваш код в объект.

var x = (function () {}) ();

2- Конфигурация объекта, фабричный образец. -Передача объекта в функцию, а не кучу переменных.

var product = factory ({});

3- функция обратного вызова. - Передать функцию в качестве параметра, который будет вызываться после завершения задачи.

function longTask (function () {// позвоните мне, когда закончите});

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

Отличный вопрос.

Надеюсь, это поможет.