JavaScript. Подробное руководство, 6-е издание, стр. 136

 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;

 }

 };

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

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

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

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

9.9. Модули

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

imports

exports

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

Многие библиотеки и клиентские фреймворки JavaScript включают собственные инструменты поддержки модулей. Например, библиотеки

Dojo

Google Closure

определяют функции

provide()

require()

для объявления и загрузки модулей. А в рамках проекта CommonJS по стандартизации серверного JavaScript (http:// commonjs.org) разработана спецификация, определяющая модули, в которой также используется функция

require().

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

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

9.9.1. Объекты как пространства имен

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

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

, мог бы импортировать класс, как показано ниже:

var Set = sets.Set; // Импортировать Set в глобальное пространство имен 

var s = new Set(1,2,3); // Теперь его можно использовать без префикса sets.