Дэвид Флэнаган - JavaScript. Подробное руководство, 6-е издание

// Object.defineProperties(dest, src.properties().descriptors());

Properties.prototype.descriptors = function() {

var о = this.o, desc = {};

this.names.forEach(function(n) {

if (lo.hasOwnProperty(n)) return;

desc[n] = Object.getOwnPropertyDescriptor(o, n);

});

return desc;

};

// Возвращает отформатированный список свойств, в котором перечислены имена,

// значения и атрибуты свойств. Термин "permanent" используется для обозначения

// ненастраиваемых свойств, "readonly" - для обозначения свойств, не доступных

// для записи, и "hidden" - для обозначения неперечислимых свойств.

// Обычные перечислимые, доступные для записи и настраиваемые свойства

// указываются в списке без атрибутов.

Properties.prototype.toString = function() {

var о = this.o; // Используется во вложенных функциях ниже

var lines = this.names.map(nameToString);

return "{\n " + lines.join(",\n ") + "\n}";

function nameToString(n) {

var s = desc = Object.getOwnPropertyDescriptor(o, n);

if (!desc) return "nonexistent " + n + ": undefined";

if (!desc.configurable) s += "permanent ";

if ((desc.get && Idesc.set) || !desc.writable) s += "readonly ";

if (!desc.enumerable) s += "hidden ";

if (desc.get || desc.set)

s += "accessor + n

else

s += n + ": " + ((typeof desc.value==="function")?"function"

:desc.value);

return s;

}

};

// Наконец, сделать методы экземпляров объекта-прототипа, объявленного

// выше, неперечислимыми, с помощью методов, объявленных здесь.

Properties.prototype.properties().hide();

}()); // Вызвать вмещающую функцию сразу после ее определения.

Важной причиной организации программного кода в классы является стремление придать этому программному коду модульную структуру и обеспечить возможность повторного его использования в различных ситуациях. Однако не только классы могут использоваться для организации модульной структуры. Обычно модулем считается один отдельный файл с программным кодом JavaScript. Файл модуля может содержать определение класса, множество родственных классов, библиотеку вспомогательных функций или просто выполняемый сценарий. Модулем может быть любой фрагмент программного кода на языке JavaScript при условии, что он имеет модульную структуру. В языке JavaScript отсутствуют какие-либо синтаксические конструкции для работы с модулями (впрочем, в нем имеются зарезервированные ключевые слова imports и exports , поэтому такие конструкции могут появиться в будущих версиях языка), поэтому написание модулей в языке JavaScript в значительной степени является вопросом следования соглашениям оформления программного кода.

Многие библиотеки и клиентские фреймворки JavaScript включают собственные инструменты поддержки модулей. Например, библиотеки Dojo и Google Closure определяют функции provide() и require() для объявления и загрузки модулей. А в рамках проекта CommonJS по стандартизации серверного JavaScript (http:// commonjs.org) разработана спецификация, определяющая модули, в которой также используется функция require(). Подобные инструменты поддержки модулей часто берут на себя такие функции, как загрузка модулей и управление зависимостями, но их обсуждение выходит за рамки этой дискуссии. Если вы пользуетесь одним из таких фреймворков, то вам следует использовать и определять модули, следуя соглашениям, принятым в этом фреймворке. А в этом разделе мы обсудим лишь самые простые соглашения.

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

Один из способов обойтись в модуле без создания глобальных переменных заключается в том, чтобы создать объект и использовать его как пространство имен. Вместо того чтобы создавать глобальные функции и переменные, их можно сохранять в свойствах объекта (на который может ссылаться глобальная переменная). Рассмотрим в качестве примера класс Set из примера 9.6. Он определяет единственную глобальную функцию-конструктор Set . Он определяет различные методы экземпляров, но сохраняет их как свойства объекта Set.prototype , благодаря чему они уже не являются глобальными. В этом примере также определяется вспомогательная функция _ v2s(), но она также сохраняется как свойство класса Set .

Далее рассмотрим пример 9.16. Этот пример объявляет несколько абстрактных и конкретных классов множеств. Для каждого класса создается единственное глобальное имя, но модуль целиком (файл с программным кодом) определяет довольно много глобальных имен. С точки зрения сохранения чистоты глобального пространства имен было бы лучше, если бы модуль с классами множеств определял единственное глобальное имя:

var sets = {};

Объект sets мог бы играть роль пространства имен модуля, а каждый из классов множеств определялся бы как свойство этого объекта:

sets.SingletonSet = sets.AbstractEnumerableSet.extend(...);

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

var s = new sets.SingletonSet(1);

Автор модуля не может заранее знать, с какими другими модулями будет использоваться его модуль, поэтому он должен принять все меры против конфликтов, используя подобные пространства имен. Однако программист, использующий модуль, знает, какие модули он использует и какие имена в них определяются. Этот программист не обязан использовать имеющиеся пространства имен ограниченно и может импортировать часто используемые значения в глобальное пространство имен. Программист, который собирается часто использовать класс Set из пространства имен sets , мог бы импортировать класс, как показано ниже: