В последнем, мы прошли в элемент. Результат всех трех, был одинаковым, - нам был возвращен jQuery объект, ссылающийся на узел DOM.

Переменная $ адаптирует строительный шаблон в jQuery. В каждом примере, нам был возвращен jQuery DOM объекти и имелся доступ ко всем методам, предоставляемых библиотекой jQuery, и не в одном из моментов, мы не вызывали document.createElement. JS library обработала все это за закрытыми дверями.

Представьте себе, как много было бы работы, если нам пришлось бы создавать элемент DOM и вставлять содержимое в него! Используя строительный шаблон, мы можем сосредоточить свое внимание на типе и содержание объекта, а не на его явном создании.

Прототипный шаблон (Prototype pattern)

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

Прототипный шаблон - это шаблон, в котором объекты создаются на основе шаблона существующего объекта путем клонирования.

Это простой и естественный способ реализации наследования в JavaScript. Например:

Var Person = { numFeet: 2, numHeads: 1, numHands:2 }; //Object.create берет свой ​​первый аргумент и применяет его к прототипу нового объекта. var tilo = Object.create(Person); console.log(tilo.numHeads); //результат 1 tilo.numHeads = 2; console.log(tilo.numHeads) //результат 2

Свойства (и методы) в Person объекте, применяются к прототипу объекта tilo. Мы можем переопределить свойства объекта tilo, если хотим, чтобы они были разными.

В приведенном выше примере, мы использовали Object.create (). Однако, Internet Explorer 8 не поддерживает новый метод. В этих случаях мы можем имитировать его поведение:

Var vehiclePrototype = { init: function (carModel) { this.model = carModel; }, getModel: function () { console.log("The model of this vehicle is " + this.model); } }; function vehicle (model) { function F() {}; F.prototype = vehiclePrototype; var f = new F(); f.init(model); return f; } var car = vehicle("Ford Escort"); car.getModel();

Структурные шаблоны

Структурные шаблоны действительно полезны, особенно при выяснении, как система должна работать. Они позволяют приложениям легко масштабироваться и оставаться управляемыми. Из этой немалой группы (адаптер, мост, компоновщик, декоратор, фасад, единая точка входа, приспособленец, заместитель), мы рассмотрим следующие модели: Компоновщик и Фасад.

Компоновщик (шаблон проектирования)

• Шаблон Компоновщик, - это ещё один вид шаблона, который вы, вероятно, использовали без осознания того.

Итак, что же это значит? Давайте, рассмотрим следующий пример в jQuery (у большинства JS библиотек будут эквиваленты этому):

$(".myList").addClass("selected"); $("#myItem").addClass("selected"); //Не делайте этого на больших таблицах, это всего лишь пример. $("#dataTable tbody tr").on("click", function(event){ alert($(this).text()); }); $("#myButton").on("click", function(event) { alert("Clicked."); });

Большинство библиотек JavaScript обеспечивают последовательное API, независимо от того, имеем мы дело с одним элементом DOM или массивом DOM элементов. В первом примере, мы можем добавить selected класс ко все элементам подобраных селектором.myList, но мы также можем использовать этот же метод, когда речь идет об еденичном DOM элементе, #myItem. Точно так же можно приложить обработчик событий с помощью on() метода на нескольких узлах, или на одном узле через тот же API.

Благодаря использованию композитных макетов, jQuery (и многие другие библиотеки) предоставляют нам упрощенный API.

Composite шаблон иногда может вызывать проблемы. В слабо расписанном языке, таком как JavaScript, полезным будет знать, имеем ли мы дело с одним элементом или несколькими элементами. Так как компоновщик шаблон использует одинаковый API для обоих, мы зачастую можем принять одно за другое и в конечном итоге столкнуться с неожиданной ошибкой. Некоторым библиотекам, таким как YUI3, предлагают два отдельных метода получения элементов (Y.one() vs Y.all()).

Фасад (шаблон проектирования)

Вот еще один паттерн, который мы воспринимаем как должное. Объект, который абстрагирует работу с несколькими классами, объединяя их в единое целое.

Фасад паттерн предоставляет пользователю простой интерфейс, скрыв его основные сложности.

Фасад шаблон, почти всегда улучшает удобство использования части программного обеспечения. Использование jQuery в качестве примера, одним из наиболее распространенных методов библиотеки, является ready() метод:

$(document).ready(function() { //весь ваш код идет сюда... });

Метод ready() фактически реализует фасад. Если взглянуть на источник, вот что вы найдете:

Ready: (function() { ... //Mozilla, Opera, и Webkit if (document.addEventListener) { document.addEventListener("DOMContentLoaded", idempotent_fn, false); ... } //IE модель событий else if (document.attachEvent) { // обеспечьте firing до onload; может быть поздно, но безопасно для iframes document.attachEvent("onreadystatechange", idempotent_fn); // Резерв для window.onload, который всегда работает window.attachEvent("onload", idempotent_fn); ... } })

Метод ready() не такой уж простой. jQuery нормализует непостоянство браузера, чтобы ready() сработал в нужный момент. Однако, как разработчик, вы будете представлены с простым интерфейсом.

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

Поведенческие шаблоны

Любая объектно-ориентированная система программного обеспечения будет иметь связи между объектами. Не организация таких связей может привести к ошибкам, которые трудно найти и исправить. Поведенческие шаблоны проектирования преписывают различные методы организации связи между объектами (цепочка ответственности, команда, интерпретатор, итератор, посредник, хранитель, наблюдатель, слуга, спецификация, состояние, стратегия, шаблонный метод, посетитель и т.д.). В этом раздел, мы рассмотрим Наблюдатель (Observer) и Посредник (Mediator) паттерны.

Шаблон Наблюдатель (Observer)

Вот что говорится о Наблюдателе:

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

Нам нужно три метода для описания этого паттерна:

publish(data): вызывается объектом, когда у него есть уведомление. Некоторые данные могут быть переданы с помощью этого метода.
subscribe(observer): вызывается объектом, для добавления наблюдателя в свой список наблюдателей.
unsubscribe(observer): вызывается объектом, чтобы удалить наблюдателя из списка наблюдателей.
Большинство современных JavaScript библиотек поддерживают эти три метода, как часть своей инфраструктуры событий. Обычно есть on() или attach() метод, trigger() или fire() метод, и off() или detach() метод. Рассмотрим следующий сниппет:

//Мы просто создаем связь между методами jQuery событий var o = $({}); $.subscribe = o.on.bind(o); $.unsubscribe = o.off.bind(o); $.publish = o.trigger.bind(o); // Usage document.on("tweetsReceived", function(tweets) { //perform some actions, then fire an event $.publish("tweetsShow", tweets); }); //Мы можем subscribe к этому событию, а затем fire наше собственное событие. $.subscribe("tweetsShow", function() { //display the tweets somehow .. //publish после того, как оно показано $.publish("tweetsDisplayed); }); $.subscribe("tweetsDisplayed, function() { ... });

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

Шаблон Посредник (Mediator)

Последний паттерн, который мы рассмотрим, это Посредник. Он похож на паттерн Наблюдатель, но с некоторыми заметными отличиями.

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

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

$("#album").on("click", function(e) { e.preventDefault(); var albumId = $(this).id(); mediator.publish("playAlbum", albumId); }); var playAlbum = function(id) { … mediator.publish("albumStartedPlaying", {songList: [..], currentSong: "Without You"}); }; var logAlbumPlayed = function(id) { //Логин альбом на бенэнде }; var updateUserInterface = function(album) { //Апдейт UI для отображения того, что играет }; //Посредник subscriptions mediator.subscribe("playAlbum", playAlbum); mediator.subscribe("playAlbum", logAlbumPlayed); mediator.subscribe("albumStartedPlaying", updateUserInterface);

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

Заключение

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

Перевод ()
Источник фото - Fotolia.ru

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

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

В этом посте я хотел бы обсудить распространённые шаблоны чтобы улучшить ваши знания в программировании и погрузиться глубже в JavaScript.

Шаблоны проектирования включают в себя следующее:

— Модуль

— Прототип

— Наблюдатель

— Одиночка

Каждый шаблон состоит из множества свойств, но я выделяю следующие ключевые моменты:

1.Контекст: Где/при каких обстоятельствах используется тот или иной шаблон?

2. Проблема: Какую проблему мы пытаемся решить?

3. Решение: Как использовать это шаблон для решения этой проблемы?

4.Реализация: Как выглядит реализация?

# Шаблон Модуль (Module )

В JavaScript модули являются наиболее распространенными шаблонами проектирования для обеспечения независимости каких-то частей кода от других компонентов. Это обеспечивает слабую связь для поддержания хорошо структурированного кода.
Для тех, кто знаком с объектно-ориентированными языками, модули - это «классы» в JavaScript . Одно из многих преимуществ классов - инкапсуляция – защита состояния и поведения от доступа из других классов.
Шаблон модуля дает доступ публичным и частным уровням (плюс менее защищенным и привилегированным).

Этот язык UML описывает интерфейс прототипа используется для клонирования конкретных реализаций.

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

var TeslaModelS = function() { this.numWheels = 4; this.manufacturer = "Tesla"; this.make = "Model S"; } TeslaModelS.prototype.go = function() { // Вращаются колеса } TeslaModelS.prototype.stop = function() { }

Конструктор позволяет создавать один объект TeslaModelS . При создании нового объекта TeslaModelS , он сохранит состояние, инициализированное в конструкторе. Кроме того, поддержание функции go и stop несложно, так как мы объявили их при помощи прототипов. Такой же способ расширения функции с использованием прототипа описан ниже:

var TeslaModelS = function() { this.numWheels = 4; this.manufacturer = "Tesla"; this.make = "Model S"; } TeslaModelS.prototype = { go: function() { // Вращаются колеса }, stop: function() { // Применяются тормозные колодки } }

REVEALING PROTOTYPE PATTERN

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

Поскольку мы возвращаем объект, мы добавим объекту-прототипу префикс функции. Дополнив наш пример, мы можем выбрать что мы хотим показать в текущем прототипе, чтобы сохранить свои уровни доступа:

var TeslaModelS = function() { this.numWheels = 4; this.manufacturer = "Tesla"; this.make = "Model S"; } TeslaModelS.prototype = function() { var go = function() { // Вращаются колеса }; var stop = function() { // Применяются тормозные колодки }; return { pressBrakePedal: stop, pressGasPedal: go } }();

Обратите внимание, как функции Stop и Go будут защищены от возвращенного объекта в связи с нахождением за пределами области видимости возвращаемого объекта. Поскольку JavaScript изначально поддерживает прототипное наследование, нет необходимости переписывать базовые элементы(или особенности или черты).

# Шаблон Наблюдатель (Observer )

Бывает так, что одна часть приложения изменяется, а другие части нуждаются в обновлении. В Angular j s, если $scope объекта обновляется, событие может быть запущено для уведомления другого компонента. Шаблон Observer включает в себя то, что, если объект изменен, то он передает (broadcasts) зависимым объектам, что изменение произошло.

Другой яркий пример архитектура модель-представление-контроллер (MVC); представление обновляется когда изменяется модель. Одним из преимуществ является разрыв связи представления от модели для уменьшения зависимостей.

Как показано на схеме UML, необходимые объекты это subject, observer , и concrete . Объект subject содержит ссылки на concrete observers для уведомления любых изменениях. Объект observer является абстрактным классом, позволяющий concrete observers реализовывать метод уведомления.

Давайте взглянем на пример AngularJS , который включает в себя шаблон Observer через управление событиями.

// Controller 1 $scope.$on("nameChanged", function(event, args) { $scope.name = args.name; }); ... // Controller 2 $scope.userNameChanged = function(name) { $scope.$emit("nameChanged", {name: name}); };

С шаблоном Observer важно различать независимый это объект или subject .

Важно отметить, что, хотя шаблон Observer и предоставляет много преимуществ, но одним из недостатков является значительное падение производительности, так как количество «наблюдателей» (observers ) увеличено. Один из самых пользующихся дурной славой наблюдателей являются watchers . В AngularJS мы можем наблюдать (watch ) переменные, функции и объекты. Цикл $$digest работает и уведомляет каждого из watchers новыми значениями всякий раз, когда область объекта изменяется.

Мы можем создать наши собственные Subjects и Observers в JavaScript . Давайте посмотрим, как это реализуется:

var Subject = function() { this.observers = ; return { subscribeObserver: function(observer) { this.observers.push(observer); }, unsubscribeObserver: function(observer) { var index = this.observers.indexOf(observer); if(index > -1) { this.observers.splice(index, 1); } }, notifyObserver: function(observer) { var index = this.observers.indexOf(observer); if(index > -1) { this.observers.notify(index); } }, notifyAllObservers: function() { for(var i = 0; i < this.observers.length; i++){ this.observers[i].notify(i); }; } }; }; var Observer = function() { return { notify: function(index) { console.log("Observer " + index + " is notified!"); } } } var subject = new Subject(); var observer1 = new Observer(); var observer2 = new Observer(); var observer3 = new Observer(); var observer4 = new Observer(); subject.subscribeObserver(observer1); subject.subscribeObserver(observer2); subject.subscribeObserver(observer3); subject.subscribeObserver(observer4); subject.notifyObserver(observer2); // Observer 2 is notified! subject.notifyAllObservers(); // Observer 1 is notified! // Observer 2 is notified! // Observer 3 is notified! // Observer 4 is notified!

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

В условиях когда клиентская часть веб-приложений становится все более толстой, бизнес-логика неумолимо переползает на клиент, а на суверенитет серверных технологий все более смело посягает node.js нельзя не задуматься о приемах проектирования архитектуры на javaScript. И в этом деле нам несомненно должны помочь паттерны проектирования - шаблонные приемы решения часто встречающихся задач. Паттерны помогают построить архитектуру, которая потребует от вас наименьших усилий при необходимости внести изменения. Но не стоит воспринимать их как панацею, т.е., грубо говоря, если качество кода «не фонтан», он кишит хардкодом и жесткой связью между логически независимыми модулями, то никакие паттерны его не спасут. Но если стоит задача спроектировать масштабируемую архитектуру, то паттерны могут стать хорошим подспорьем.
Но впрочем эта статья не о паттернах проектирования как таковых, а о их применении в javaScript. В первой части этой статьи я напишу о применении порождающих паттернах.

Singleton

Var app = { property1: "value", property2: "value", ... method1: function () { ... }, ... }

Этот способ имеет как свои преимущества, так и недостатки. Его просто описать, многие его используют не догадываясь о существовании каких-либо паттернов и эта форма записи будет понятна любому javaScript разработчику. Но у него есть и существенный недостаток: основная цель паттерна singleton - обеспечить доступ к объекту без использования глобальных переменных, а данный способ предоставляет доступ к переменной app только в текущей области видимости. Это означает, что к объекту app мы сможем обратиться из любого места приложения только в том случае если он будет глобальным. Чаще всего это крайне неприемлемо, хорошим стилем разработки на javaScript является использование максимум одной глобальной переменной, в которой инкапсулируется все необходимое. А это означает, что приведенный выше подход мы сможем использовать максимум один раз в приложении.
Второй способ чуть более сложен, но зато и более универсален:

Function SomeFunction () { if (typeof (SomeFunction.instance) == "object") { return SomeFunction.instance; } this.property1 = "value"; this.property2 = "value"; SomeFunction.instance = this; return this; } SomeFunction.prototype.method1 = function () { }

Теперь, используя любую модульную систему (например requirejs) мы в любом месте нашего приложения сможем подключить файл с описанием этой функции-конструктора и получим доступ к нашему объекту, выполнив:

Var someObj = new SomeFunction ();

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

Function SomeFunction () { var instance; SomeFunction = function () { return instance; } this.property1 = "value"; this.property2 = "value"; instance = this; }

Казалось бы вот оно, решение всех проблем, но на место старых проблем приходят новые. А именно: все свойства, занесенные в прототип конструктора после создания экземпляра не будут доступны, т.к. по сути будут записаны в старый конструктор, а не в свежеопределенный. Но и из этой ситуации есть достойный выход:

Function SomeFunction () { var instance; SomeFunction = function () { return instance; } SomeFunction.prototype = this; instance = new SomeFunction (); instance.constructor = SomeFunction; instance.property1 = "value"; instance.property2 = "value"; return instance; }

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

Define(, function () { var instance = null; function SomeFunction() { if (instance) { return instance; } this.property1 = "value"; this.property2 = "value"; instance = this; }; return SomeFunction; });

Factory method

Function Foo () { //... } function Bar () { //... } function factory (type) { switch (type) { case "foo": return new Foo(); case "bar": return new Bar(); } }

Соответственно создание объектов будет выглядеть так:

Foo = factory("foo"); bar = factory("bar");

Можно использовать более элегантное решение:

Function PetFactory() { }; PetFactory.register = function(name, PetConstructor) { if (name instanceof Function) { PetConstructor = name; name = null; } if (!(PetConstructor instanceof Function)) { throw { name: "Error", message: "PetConstructor is not function" } } this = PetConstructor; }; PetFactory.create = function(petName) { var PetConstructor = this; if (!(PetConstructor instanceof Function)) { throw { name: "Error", message: "constructor "" + petName + "" undefined" } } return new PetConstructor(); };

В этом случае мы не ограничиваем себя количеством классов, которые может порождать фабрика, можем добавлять их сколько угодно таким способом:

PetFactory.register("dog", function() { this.say = function () { console.log("gav"); } });

Ну или таким:

Function Cat() { } Cat.prototype.say = function () { console.log("meow"); } PetFactory.register(Cat);

Abstract Factory

Function BluePopup () { //создание всплывающего окна } BluePopup.prototype.attach = function (elemens) { //присоединение других ui-элементов к окну } BluePopupFactory.register("popup", BluePopup); function BluePopupButton () { //создание кнопки для синего всплывающего окна } BluePopupButton.prototype.setText = function (text) { //установка текста на кнопке } BluePopupFactory.register("button", BluePopupButton); function BluePopupTitle () { //создание заголовка для синего окна } BluePopupTitle.prototype.setText = function (text) { //установка текста заголовка } BluePopupFactory.register("title", BluePopupTitle);

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

Function UI () { //класс, отвечающий за ui-элементы }

И в него мы добавим метод createPopup:

UI.createPopup = function (factory) { var popup = factory.create("popup"), buttonOk = factory.create("button"), buttonCancel = factory.create("button"), title = factory.create("title"); buttonOk.setText("OK"); buttonCancel.setText("Cancel"); title.setText("Untitled"); popup.attach(); }

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

Var newPopup = UI.createPopup(BluePopupFactory);

Соответственно, можно описать неограниченное количество фабрик и передавать нужную при создании очередного всплывающего окна.