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

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

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

Шаблон прототипа

Ранее мы рассмотрели, как определить типы данных в JavaScript через функции и добавить методы к prototype объекта. Шаблон Prototype позволяет объектам наследовать от других объектов через их прототипы.

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

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

Var Person = { numFeet: 2, numHeads: 1, numHands:2 }; //Object.create takes its first argument and applies it to the prototype of your new object. var tilo = Object.create(Person); console.log(tilo.numHeads); //outputs 1 tilo.numHeads = 2; console.log(tilo.numHeads) //outputs 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();

Единственным недостатком этого метода является то, что вы не можете указывать свойства только для чтения, которые могут быть указаны при использовании Object.create() . Тем не менее, образец прототипа показывает, как объекты могут наследоваться от других объектов.

Структурные шаблоны проектирования

Структурные шаблоны проектирования действительно полезны при определении того, как система должна работать. Они позволяют нашим приложениям легко масштабироваться и оставаться обслуживаемыми. Мы рассмотрим следующие шаблоны в этой группе: Composite и Facade.

Композитный шаблон

composite шаблон - это еще один шаблон, который вы, вероятно, использовали раньше, без какой-либо реализации.

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

Так что это значит? Ну, рассмотрим этот пример в jQuery (у большинства JS-библиотек будет эквивалент этого):

$(".myList").addClass("selected"); $("#myItem").addClass("selected"); //dont do this on large tables, it"s just an example. $("#dataTable tbody tr").on("click", function(event){ alert($(this).text()); }); $("#myButton").on("click", function(event) { alert("Clicked."); });

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

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

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

Фасад

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

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

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

$(document).ready(function() { //all your code goes here... });

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

Ready: (function() { ... //Mozilla, Opera, and Webkit if (document.addEventListener) { document.addEventListener("DOMContentLoaded", idempotent_fn, false); ... } //IE event model else if (document.attachEvent) { // ensure firing before onload; maybe late but safe also for iframes document.attachEvent("onreadystatechange", idempotent_fn); // A fallback to window.onload, that will always work 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() . Рассмотрим следующий фрагмент:

//We just create an association between the jQuery events methods //and those prescribed by the Observer Pattern but you don"t have to. 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); }); //We can subscribe to this event and then fire our own event. $.subscribe("tweetsShow", function() { //display the tweets somehow .. //publish an action after they are shown. $.publish("tweetsDisplayed); }); $.subscribe("tweetsDisplayed, function() { ... });

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

Посредник

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

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

Хорошей аналогией в реальном мире будет вышка в аэропорте, которая обрабатывает связь между аэропортом и рейсами. В мире разработки программного обеспечения шаблон 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) { //Log the album in the backend }; var updateUserInterface = function(album) { //Update UI to reflect what"s being played }; //Mediator subscriptions mediator.subscribe("playAlbum", playAlbum); mediator.subscribe("playAlbum", logAlbumPlayed); mediator.subscribe("albumStartedPlaying", updateUserInterface);

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

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

Заключение

Кто-то уже успешно применял это в прошлом.

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

Для дополнительного чтения

Большая часть контента из этой статьи находится в отличной книге « » Адди Османи. Это онлайн-книга, которая была выпущена бесплатно под лицензией Creative Commons. Книга широко охватывает теорию и реализацию множества различных шаблонов, как в ванильном JavaScript, так и в различных JS-библиотеках. Я призываю вас заглянуть в нее, когда вы начнете свой следующий проект.

Эта статья раскрывает варианты применения паттернов среднего и сложного уровня к пространствам имён(Namespace) в JavaScript.

• Паттерн (англ. "pattern - образец, шаблон, система) - Смысл термина «паттерн» больше уже чем просто «образец», и варьируется в зависимости от области знаний, в которой используется. Паттерн (информатика) - эффективный способ решения характерных задач проектирования, в частности проектирования компьютерных программ.

Что такое Namespacing в JavaScript

Во многих языках программирования Namespacing является ключевой техникой позволяющей избежать путаницы объектов в глобальном пространстве имён. Более того, качественная организация Namespace позволяет сгруппировать функциональные блоки в контролируемые группы, которые могут быть в последующем однозначно идентифицированы.

Организация пространств имён JavaScript на уровне бизнесс-логики имеет решающее значение. Это позволяет обезопасить приложение от взлома или подмены оригинального кода внедрёнием методов и переменных имеющих такие-же характеристики. Риск инъекции стороннего кода в приложения в наши дни являться серьёзной причиной обезопасить свою карьеру. И дело не только в чистоте глобального пространства имён, но и в возможных конфликтах с приложениями других разработчиков.

Не смотря на то, что JavaScript не имеет встроенной поддержки Namespace, как другие языки программирования, в нём есть объекты и closeure(замыкания), которые позволяют достичь нужного эффекта.

Продвинутые паттерны организации Namespace

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

Автоматизация вложенных(nested) Namespace

Возможно, вам известно, что nested Namespace представляет собой иерархическую организацию структур. Рассмотрим, как структура вида application.utilities.drawing.canvas.2d может выглядеть на практике. Применительно к JavaScript это литерал-объект:

Var application = { utilities:{ drawing:{ canvas:{ 2d:{ /*...*/ } } } } };

Ух, это уныло.

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

Как решить эту проблему изящнее? В книге JavaScript Patterns Стоян Стефанов предлагает весьма грамотный подход для организации вложенных пространств имён при существующей глобальной переменной. Метод принимает однострочный аргумент для гнезда, парсит его и автоматически заполняет Namespace вместе с требуемыми объектами.

Предлагаемый им метод я изменил до кондиции общей функции, которую можно повторно использовать при работе с несколькими пространствами имён:

// верхний уровень namespace объявлен как литерал-объект var myApp = myApp || {}; // функция для разборки строки Namespace и автоматической генерации вложенной иерархии function extend(ns, ns_string) { var parts = ns_string.split("."), parent = ns, pl, i; if (parts == "myApp") { parts = parts.slice(1); } pl = parts.length; for (i = 0; i < pl; i++) { //create a property if it doesnt exist if (typeof parent] == "undefined") { parent] = {}; } parent = parent]; } return parent; } // пример применения: расширение myApp с глубокой вложенностью namespace var mod = extend(myApp, "myApp.modules.module2"); // на выходе: корректно вложенная в объект иерархия console.log(mod); // мы можем проверить это используя экземпляр объекта за пределами myApp namesapce, // как клон, включающий в себя расширения console.log(mod == myApp.modules.module2); //true // следом, более простая демонстрация объявления с использованием extend extend(myApp, "moduleA.moduleB.moduleC.moduleD"); extend(myApp, "longer.version.looks.like.this"); console.log(myApp);

Вот что мы увидим в web-инспекторе:

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

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

Шаблон зависимых объявлений

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

// общий подход к доступу пространств имён

MyApp.utilities.math.fibonacci(25); myApp.utilities.math.sin(56); myApp.utilities.drawing.plot(98,50,60);

// объявление локальных(кешируемых) ссылок

Var utils = myApp.utilities, maths = utils.math, drawing = utils.drawing;

// более короткий путь к namespace

Maths.fibonacci(25); maths.sin(56); drawing.plot(98, 50,60);

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

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

Стоян рекомендует объявлять локальные Namespace требуемых функций или модулей в верху иерархии приложения(с использованием шаблона единичной переменной) и называет такую модель «шаблон зависимых объявлений». Одним из достоинств данного метода является снижение числа возможных зависимостей и поиска решений по их устранению, если у вас расширяемая архитектура, которая загружает модули динамически, по мере их надобности.

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

Глубинные расширения объектов

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

Это как раз то, что стало легко выполнимо с помощью JavaScript фреймворков(например, метод jQuery $.extend). Тем не менее, если вам нужно повторить это в стиле «vanila js», следующие инструкции могут быть полезны.

// extend.js // written by andrew dupont, optimized by addy osmani

Function extend(destination, source) { var toString = Object.prototype.toString, objTest = toString.call({}); for (var property in source) { if (source && objTest == toString.call(source)) { destination = destination || {}; extend(destination, source); } else { destination = source; } } return destination; }; console.group("objExtend namespacing tests");

// определение top-level namespace

Var myNS = myNS || {};

// 1. расширение namespace объектом "utils"

Extend(myNS, { utils:{ } }); console.log("test 1", myNS);

// myNS.utils теперь существует // 2. расширение объекта несколькими значениями (namespace.hello.world.wave)

Extend(myNS, { hello:{ world:{ wave:{ test: function(){ /*...*/ } } } } });

// проверка ссылок на работоспособность

MyNS.hello.test1 = "this is a test"; myNS.hello.world.test2 = "this is another test"; console.log("test 2", myNS);

// 3. а что если myNS уже имеет namespace (например, "library")?

MyNS.library = { foo:function(){} }; extend(myNS, { library:{ bar:function(){ /*...*/ } } });

// проверим работает ли extend так как ожидалось myNS сейчас содержит library.foo и library.bar

Console.log("test 3", myNS);

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

Var shorterAccess1 = myNS.hello.world; shorterAccess1.test3 = "hello again"; console.log("test 4", myNS);

// победа, myApp.hello.world.test3 теперь доступно через "hello again"

Console.groupEnd();

Если же ваше приложение использует jQuery, то расширения namespace объекта можно достичь с помощью $.extend.

// top-level namespace

Var myApp = myApp || {};

// явное расширение namespace вглубь

MyApp.library = { foo:function(){ /*..*/} };

// расширим наш namespace другим объектом, но // чтобы было интереснее сделаем вложенное пространство имён функцией // $.extend(deep, target, object1, object2)

$.extend(true, myApp, { library:{ bar:function(){ /*..*/ } } }); console.log("test", myApp);

// myApp теперь содержит методы library.foo() и library.bar() // ни одно из namespace не подверглось корреляции, на что мы и рассчитывали.

Для большей наглядности посмотрите другие примеры $.extend и поэкспериментируйте с ними.

Основы построения пространств имён

Пространства имён встречаются в любом мало-мальски серьёзном приложении. Если вы работаете с разрозненными фрагментами кода, то делаете максимум возможного, чтобы убедиться, что пространства имён организованы правильно. Это защищает данные вашего приложения от перспективы быть затёртым другим приложением. В этом разделе мы будем рассматривать следующие шаблоны:

1. Одиночные глобальные переменные (Single global variables)
2. Объектно-буквенное обозначение (Object literal или литерал-объект)
3. Глубинное именование (Nested namespacing)
4. Объявление самовызывающейся функции (Immediately-invoked Function Expressions)
5. Внедрение в Namespace (Namespace injection)

Одиночные глобальные переменные

Одним из популярных шаблонов для организации Namespace в JavaScript является выбор одной глобальной переменной в качестве основного объекта для ссылки. Каркас такого паттерна возвращает объект с функцией и свойствами:

Var myApplication = (function(){ function(){ /*...*/ }, return{ /*...*/ } })();

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

Возможный вариант решения упоминался Петер Мичаукс. Решение заключается в довольно простой идее использовать префиксы для имён. Сначала вы именуете своё приложение, а затем объекты, методы, функции или свойства, например:

Var myApplication_propertyA = {}; var myApplication_propertyB = {}; funcion myApplication_myMethod(){ /*..*/ }

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

Если вас интересует мнение Петера в отношении этого вопроса, можете прочитать статью на эту тему.

Object literal notation

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

Var myApplication = { getInfo:function(){ /**/ }, // мы также можем организовать литерал-объект для надёжности models: {}, views: { pages: {} }, collections: {} };

Естественно, мы можем определить какие-то свойства для Namespace напрямую.

MyApplication.foo = function(){ return "bar"; } myApplication.utils = { toString:function(){ /*..*/ }, export: function(){ /*..*/ } }

Шаблон «Object literal notation» имеет достоинства не загрязнять глобальное пространство имён, помогать в логической организации кода и параметров. Это очень полезно, если вы хотите создавать легко читаемые структуры кода, которые могут быть в последующем расширяться вглубь. В отличие от обычных глобальных переменных объектно-буквенный namespace также учитывают тесты на существование переменной, поэтому шансы на путаницу значительно сокращаются.

Следующий фрагмент кода демонстрирует способы, которыми вы можете проверить наличие переменной(namespace) в глобальном пространстве, перед тем, как определить её. Вы будете чаще встречать вариант 1, однако, варианты 3 и 5 являются более тщательными, в то время, как вариант 4 считается лучшей практикой.

// Плохо: // этот вариант не предусматривает проверки глобального namespace на наличие "myApplication".

Var myApplication = {};

/* Следующие методы предназначены для проверки на существование переменной.

Если переменная существует, используется экземпляр. В противном случае создаётся новый литерал-объект для myApplication

Var myApplication = myApplication || {};

If(!MyApplication) MyApplication = {};

Var myApplication = myApplication = myApplication || {}

MyApplication || (myApplication = {});

Var myApplication = myApplication === undefined ? {} : myApplication;

Существует огромное количество мнений, как именно использовать литерал-объект для проектирования структуры приложений. Для организации вложенных API применимо к отдельно взятым модулям вы можете поискать свой способ возвращать интерфейс для удобства других разработчиков. Это вариация модульного шаблона на основе паттерна «IIFE» с применением интерфейса на базе литреал-объекта.

Var namespace = (function () { // объявление в локальной области var privateMethod1 = function () { /* ... */ } var privateMethod2 = function () { /* ... */ } var privateProperty1 = "foobar"; return { // здесь мы возвращаем литерал-объект, который может иметь // столько уровней в глубину, сколько вы пожелаете. // но, как упоминалось выше, этот вариант лучше всего подходит // небольших приложений с ограниченной областью видимости publicMethod1: privateMethod1, //вложенные пространства имён с публичными свойствами properties:{ publicProperty1: privateProperty1 }, //ещё одно адресное пространство utils:{ publicMethod2: privateMethod2 } ... } })();

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

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

Var myConfig = { language: "english", defaults: { enableGeolocation: true, enableSharing: false, maxPhotos: 20 }, theme: { skin: "a", toolbars: { index: "ui-navigation-toolbar", pages: "ui-custom-toolbar" } } }

Стоит обратить внимание на то, что существуют незначительные отличия в синтаксисе при определении литерал-объекта и стандартного набора данных в формате JSON. Если вы по какой либо причине склоняетесь к JSON для организации параметров(например, для более удобного обмена с back-end частью приложения), не стесняйтесь. Более подробно о литерал-объекте можно узнать в статье Реббека Мерфи.

Вложенные именования

«Nested namespace» является расширением шаблона литерал-объекта. Это ещё одна распространённая модель обеспечивающая снижение рисков путаницы также и в локальной области видимости.

Возможно вы уже где-то видели это?

YAHOO.util.Dom.getElementsByClassName("test");

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

Var myApp = myApp || {};

// проверки на существование в т.ч. при определении потомков

MyApp.routers = myApp.routers || {}; myApp.model = myApp.model || {}; myApp.model.special = myApp.model.special || {};

// вложенное пространство имён может быть таким сложным, как потребуется // myApp.utilities.charting.html5.plotGraph(/*..*/); // myApp.modules.financePlanner.getSummary(); // myApp.services.social.facebook.realtimeStream.getLatest();

Для определения новых вложенных namespace вы можете обратиться к свойствам по индексу.

MyApp["routers"] = myApp["routers"] || {}; myApp["models"] = myApp["models"] || {}; myApp["controllers"] = myApp["controllers"] || {};

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

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

Объявление самовызывающейся функции (IIFE)

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

Простейшая реализация IIFE может выглядеть следующим образом:

// immediately-invoked function expression (анонимная)

(function(){ /*...*/})();

// immediately-invoked function expression (именованная)

(function foobar(){ /*..*/}());

// техника для реализации самовызова функции из внутреннего контекста

Function foobar(){ foobar(); }

Чуть более развёрнутый вариант будет таким:

Var namespace = namespace || {};

// здесь объект namespace представлен, как параметр функции

// с объявлением публичных методов и их свойств

(function(o){ o.foo = "foo"; o.bar = function(){ return "bar"; }; })(namespace); console.log(namespace);

Для большей наглядности этот пример может быть развёрнут до уровня видимости различных уровней приватности(public/private функций и переменных) и удобного обозрения namespace-расширений. Взглянем на следующий пример:

// 1. namespace может быть изменено локально и не может быть перезаписано вне своего контекста

// 2.значение undefined гарантирует, что параметры действительно не определены.

// это обезопасит приложение от подмены входных данных(mutable pre-ES5).

;(function (namespace, undefined) { // private properties var foo = "foo", bar = "bar"; // public methods and properties namespace.foobar = "foobar"; namespace.sayHello = function () { speak("hello world"); }; // private method function speak(msg) { console.log("You said: " + msg); }; // проверим есть ли "namespace" в глобальном контексте; если нет, то объявим window.namespace литерал-объектом. }(window.namespace = window.namespace || {});

// проверим наши свойства

Console.log(namespace.foobar); // foobar namescpace.sayHello(); // hello world

// попробуем определить новые

Namespace.foobar2 = "foobar"; console.log(namespace.foobar2);

Расширения(или extensions) несомненно являются ключом к любой масштабируемой модели namespace и IIFE может быть весьма эффективно использованы для этих целей. В следующем примере, "namespace" вновь передаётся в качестве аргумента в анонимную функцию и далее расширяется.

// давайте расширим namespace новой функциональностью

(function(namespace, undefined){ // public method namespace.sayGoodbye = function(){ console.log(namespace.foo); console.log(namespace.bar); speak("goodbye"); } }(window.namespace = window.namespace || {});

// в результате

Namespace.sayGoodbye(); //goodbye

Если вам интересно чуточку больше, то вы можете почитать пару заметок о анонимных функциях Бена и о namespace-паттернах в C# Элии Мэнора.

Внедрение в namespace (Namespace injection)

«Namespace injection» является ещё одним из вариантов IIFE, когда мы вводим методы или свойства в определённое пространство имён из функции обёртки, используя это в качестве мини прокси-сервера. Преимущество данного паттерна заключается в лёгкости применения определённого поведения к нескольким объектам или namespace. Также это может быть полезно при определении базовых методов, которые могут быть в последующем использованы(getters и setters).

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

Следующий пример показывает, как мы можем использовать Namespace injection для заполнения параллельно двух namespace. Одно из них utils, а второе его часть подключаемая динамически в пространстве имён tools.

Ангус Кролл ранее предлагал идею использования «call API» для обеспечения более естественного разделения между контекстами и аргументами. Такой паттерн представляет собой нечто большее, чем формирователь модулей, но в самих модулях по прежнему предполагается инкапсуляция. Вкратце это выглядит так:

// объявим namespace, котрый используем позже

Var ns = ns || {}, ns2 = ns2 || {};

// формирователь

Var creator = function(val){ var val = val || 0; this.next = function(){ return val++ }; this.reset = function(){ val = 0; } } creator.call(ns);

// ns.next, ns.reset теперь созадны

Creator.call(ns2, 5000);

// ns2 содержит некий набор методов, но с перезаписанным значением 5000 Как отмечалось выше, данный шаблон полезен для назначения базового функционала нескольких модулей или namespace. Однако, я предлагаю вам использовать его только тогда, когда использовать замыкания для прямого доступа не имеет смысла.

В заключение

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

IIFEs и «single global variable» могут неплохо работать как для построения малых и средних приложений, так и для больших объемов кода с глубокой вложенностью. Данная модель достигает своих целей читабельности и масшабируемости достаточно хорошо.

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

This UML describes how a prototype interface is used to clone concrete implementations.

To clone an object, a constructor must exist to instantiate the first object. Next, by using the keyword prototype variables and methods bind to the object"s structure. Let"s look at a basic example:

Var TeslaModelS = function() { this.numWheels = 4; this.manufacturer = "Tesla"; this.make = "Model S"; } TeslaModelS.prototype.go = function() { // Rotate wheels } TeslaModelS.prototype.stop = function() { // Apply brake pads }

The constructor allows the creation of a single TeslaModelS object. When a creating new TeslaModelS object, it will retain the states initialized in the constructor. Additionally, maintaining the function go and stop is easy since we declared them with prototype . A synonymous way to extend functions on the prototype as described below:

Var TeslaModelS = function() { this.numWheels = 4; this.manufacturer = "Tesla"; this.make = "Model S"; } TeslaModelS.prototype = { go: function() { // Rotate wheels }, stop: function() { // Apply brake pads } }

Revealing Prototype Pattern

Similar to Module pattern, the Prototype pattern also has a revealing variation. The Revealing Prototype Pattern provides encapsulation with public and private members since it returns an object literal.

Since we are returning an object, we will prefix the prototype object with a function . By extending our example above, we can choose what we want to expose in the current prototype to preserve their access levels:

Var TeslaModelS = function() { this.numWheels = 4; this.manufacturer = "Tesla"; this.make = "Model S"; } TeslaModelS.prototype = function() { var go = function() { // Rotate wheels }; var stop = function() { // Apply brake pads }; return { pressBrakePedal: stop, pressGasPedal: go } }();

Note how the functions stop and go will be shielded from the returning object due to being outside of returned object"s scope. Since JavaScript natively supports prototypical inheritance, there is no need to rewrite underlying features.

There are many times when one part of the application changes, other parts needs to be updated. In AngularJS, if the $scope object updates, an event can be triggered to notify another component. The observer pattern incorporates just that - if an object is modified it broadcasts to dependent objects that a change has occurred.

Another prime example is the model-view-controller (MVC) architecture; The view updates when the model changes. One benefit is decoupling the view from the model to reduce dependencies.

Wikipedia

As shown in the UML diagram, the necessary objects are the subject , observer , and concrete objects. The subject contains references to the concrete observers to notify for any changes. The Observer object is an abstract class that allows for the concrete observers to implements the notify method.

Let"s take a look at an AngularJS example that encompasses the observer pattern through event management.

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

With the observer pattern, it is important to distinguish the independent object or the subject .

It is important to note that although the observer pattern does offer many advantages, one of the disadvantages is a significant drop in performance as the number of observers increased. One of the most notorious observers is watchers . In AngularJS, we can watch variables, functions, and objects. The $$digest cycle runs and notifies each of the watchers with the new values whenever a scope object is modified.

We can create our own Subjects and Observers in JavaScript. Let"s see how this is implemented:

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!

Publish/Subscribe

The Publish/Subscribe pattern, however, uses a topic/event channel that sits between the objects wishing to receive notifications (subscribers) and the object firing the event (the publisher). This event system allows code to define application-specific events that can pass custom arguments containing values needed by the subscriber. The idea here is to avoid dependencies between the subscriber and publisher.

This differs from the Observer pattern since any subscriber implementing an appropriate event handler to register for and receive topic notifications broadcast by the publisher.

Many developers choose to aggregate the publish/subscribe design pattern with the observer though there is a distinction. Subscribers in the publish/subscribe pattern are notified through some messaging medium, but observers are notified by implementing a handler similar to the subject.

In AngularJS, a subscriber "subscribes" to an event using $on("event", callback), and a publisher "publishes" an event using $emit("event", args) or $broadcast("event", args).

Singleton

A Singleton only allows for a single instantiation, but many instances of the same object. The Singleton restricts clients from creating multiple objects, after the first object created, it will return instances of itself.

Finding use cases for Singletons is difficult for most who have not yet used it prior. One example is using an office printer. If there are ten people in an office, and they all use one printer, ten computers share one printer (instance). By sharing one printer, they share the same resources.

Var printer = (function () { var printerInstance; function create () { function print() { // underlying printer mechanics } function turnOn() { // warm up // check for paper } return { // public + private states and behaviors print: print, turnOn: turnOn }; } return { getInstance: function() { if(!printerInstance) { printerInstance = create(); } return printerInstance; } }; function Singleton () { if(!printerInstance) { printerInstance = intialize(); } }; })();

The create method is private because we do not want the client to access this, however, notice that the getInstance method is public. Each officer worker can generate a printer instance by interacting with the getInstance method, like so:

Var officePrinter = printer.getInstance();

In AngularJS, Singletons are prevalent, the most notable being services, factories, and providers. Since they maintain state and provides resource accessing, creating two instances defeats the point of a shared service/factory/provider.

Race conditions occur in multi-threaded applications when more than one thread tries to access the same resource. Singletons are susceptible to race conditions, such that if no instance were initialized first, two threads could then create two objects instead of returning and instance. This defeats the purpose of a singleton. Therefore, developers must be privy to synchronization when implementing singletons in multithreaded applications.

Conclusion

Design patterns are frequently used in larger applications, though to understand where one might be advantageous over another, comes with practice.

Before building any application, you should thoroughly think about each actor and how they interact with one another. After reviewing the Module , Prototype , Observer , and Singleton design patterns, you should be able to identify these patterns and use them in the wild.

Возможно, вы уже знакомы с такими фреймворками/библиотеками как ReactJS, Angular или jQuery, но знаете ли вы, зачем они были созданы? Какую проблему решают? Какой шаблон проектирования используют? Шаблоны проектирования очень важно знать, и, могу предположить, некоторые из разработчиков-самоучек могли их пропустить. Так что же такое шаблоны проектирования? Что они делают? Как мы можем их использовать? Почему их следует использовать?

Что такое шаблоны проектирования и зачем их использовать?

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

Шаблоны проектирования - проверенный способ для решения проблем. Они не включают в себя такие очевидные вещи, как использование for loop для перебора элементов массива. Их используют для решения более сложных проблем, с которыми мы сталкиваемся при разработке больших приложений.

Некоторые из плюсов использования шаблонов проектирования:

• Не нужно изобретать велосипед (ленивый программист => хороший программист)
• Находишь общий язык с разработчиками
• Выглядишь круто и профессионально
• Если ты самоучка, то это поможет тебе изрядно выделиться среди конкурентов
• Эти шаблоны проходят сквозь все языки программирования

Типы шаблонов и примеры некоторых из них

Порождающие шаблоны (Creational): создание новых объектов.

1. Конструктор (Constructor)
2. Модульный (Module)
3. Фабричный метод (Factory)
4. Одиночка (Singletion)

Структурные шаблоны(Structural): упорядочивают объекты.

1. Декоратор(Decorator)
2. Фасад (Façade)

Поведенческие (Behavioral): как объекты соотносятся друг с другом.

1. Наблюдатель(Observer)
2. Посредник(Mediator)
3. Команда(Command)

Порождающее шаблоны

Эти шаблоны используются для создания новых объектов.

Constructor

Создает новые объекты в их собственной области видимости.

// Constructor Pattern //
// Используйте для создания новых объектов в их собственной области видимости. var Person = function(name, age, favFood) {
this.name = name;
this.age = age;
this.favFood = favFood;
}; // Прототип позволяет всем экземплярам Person ссылаться на него без повторения функции.
Person.prototype.greet = function() {
console.log(`Hello, my name is ${this.name}, I"m ${this.age} years old, and my favorite food is ${this.favFood}`); // new создает объект {} и передает "this" в конструктор
// Конструктор устанавливает значение для этого объекта и возвращает его.
var bob = new Person("Bob", 22, "Chicken");
bob.greet();
// Hello, my name is Bob, I"m 22 years old, and my favorite food is Chicken // ES6 / ES2015 Классы
class Vehicle {
constructor(type, color) {
this.type = type;
this.color = color;
} getSpecs() {
console.log(`Type: ${this.type}, Color: ${this.color}`);
}
}; var someTruck = new Vehicle("Truck", "red");
someTruck.getSpecs();

Module

Используйте для инкапсуляции методов.

// Module Pattern //
// Используется для инкапсуляции кода var myModule = (function() {
// Приватная переменная
var memes = ["cats", "doge", "harambe"];

Var getMemes = function() {
return memes;
}; // возвращает то, к чему вы хотите разрешить доступ в объекте
// то, как он это возвращает действительно делает его показателем модульного шаблона проектирования return {
getMemes: getMemes
};
})(); console.log(myModule.getMemes()); // массив мемов
console.log(myModule.memes); // undefined

Factory

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

// Factory Pattern //
// Несколько конструкторов для нашей фабрики function Cat(options) {
this.sound = "Meow";
this.name = options.name;
} function Dog(options) {
this.sound = "Rawr";
this.name = options.name;
} // Animal Factory
function AnimalFactory() {} // Тип Cat по умолчанию
AnimalFactory.prototype.animalType = Cat; // метод для создания новых животных
AnimalFactory.prototype.createAnimal = function(options) {
switch(options.animalType) {
case "cat":
this.animalType = Cat;
break;
case "dog":
this.animalType = Dog;
break;
default:
this.animalType = Cat;
break;
} return new this.animalType(options);
} var animalFactory = new AnimalFactory();
var doge = animalFactory.createAnimal({
animalType: "dog",
name: "Doge"
}); var snowball = animalFactory.createAnimal({name: "Snowball"}); console.log(doge instanceof Dog); // true
console.log(doge); // выводит doge как cat объект
console.log(snowball instanceof Cat); // true
console.log(snowball); // выводит snowball как cat объект

Singleton

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

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

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

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

Как создаются объекты и какие взаимоотношения между ними. Расширяет или упрощает функциональность.

Decorator

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

// Decorator Pattern //
// Простой конструктор var Person = function (name) {
this.name = name;
} Person.prototype.greet = function () {
console.log(`Hello, my name is ${this.name}`);
} var uniqueBob = new Person("Bob"); // может быть добавлено к нему без изменения конструктора Person
uniqueBob.hobbies = ["Cooking", "Running"]; uniqueBob.greet = function() {
console.log("My hobbies are: ", this.hobbies);
}; uniqueBob.greet(); // Другой способ
var CoolPerson = function(name, catchPhrase) {
Person.call(this, name);
this.catchPhrase = catchPhrase;
}; // включает в себя prototypes от Person
CoolPerson.prototype = Object.create(Person.prototype); // изменяет прототип
CoolPerson.prototype.greet = function() {
Person.prototype.greet.call(this);
console.log(this.catchPhrase);
}; var coolDude = new CoolPerson("Jeff", "Aaaayyy");
console.log(coolDude);
coolDude.greet();

Facade

Используйте для создания простого интерфейса (упрощает функциональность , как например jQuery).

// Facade Pattern //
// абстрагирует он некоторых сложных/неряшлевых вещей var $ = function (target) {
return new MemeQuery(target);
}; function MemeQuery (target) {
this.target = document.querySelector(target);
} MemeQuery.prototype.html = function(html) {
this.target.innerHTML = html;
return this;
}; // теперь, все, что мы будем видеть и использовать это $
$("#myParagraph").html("Meeemee").html("Some JS design patterns"); //окей, возможно это и не лучший пример..
// просто посмотрите в исходный код jQuery, там полно примеров фасада
// он нужен просто для того, чтоб увести нас от того, чтоб заострять внимание на сложностях проектирования и сделать проектирование быстрее и проще.

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

Распределяют обязанности между объектами и тем, как они сообщаются.

Observer

Позволяет объектам наблюдать за объектами и быть оповещенными об изменениях.

// Observer Pattern //
// https://github.com/CodeDraken/emtr/blob/master/emitter.js

Mediator

Один объект контролирует сообщение между объектами, поэтому объекты не сообщаются друг с другом на прямую.

// Mediator Pattern //
// Извините, я очень устал для того, чтоб придумывать примеры:P

Command

Инкапсулирует вызов метода в один объект.

// Command Pattern //
// Пример из:
(function(){
var carManager = { // Запросить информацию
requestInfo: function(model, id){
return "The information for " + model + " with ID " + id + " is foobar";
},
// Купить машину
buyVehicle: function(model, id){
return "You have successfully purchased Item " + id + ", a " + model;
}, // Организвать прсмотр
arrangeViewing: function(model, id){
return "You have successfully booked a viewing of " + model + " (" + id + ") ";
}
};
})(); carManager.execute = function (name) {
return carManager && carManager.apply(carManager, .slice.call(arguments, 1));
}; carManager.execute("arrangeViewing", "Ferrari", "14523");
carManager.execute("requestInfo", "Ford Mondeo", "54323");

Фуух, сколько этих шаблонов… Я надеюсь, вы еще здесь, потому что у нас осталось еще 22 шаблона для рассмотрения. Шучу, это все! Но есть еще шаблоны, которые следует изучить, поэтому я добавлю ссылки для тех, кто хочет узнать об этом побольше.

P.S. Это мой первый перевод для medium. Спасибо всем, что прочитали! Надеюсь, вы действительно узнали что-то новое. Буду рада услышать ваши комментарии!