Вероятно, в каком-то виде вы уже используете модули в своей существующей архитектуре. Если это не так, то в этой главе я покажу вам, как они устроены.
В некоторых реализациях модули могут иметь свои собственные зависимости, которые
будут загружены автоматически, собирая вместе таким образом все компоненты
системы. Такой подход считается более масштабируемым, в отличие от ручной
загрузки модулей или подстановки тега script.
Каждое нетривиальное приложение должно создаваться из модульных компонентов. Рассмотрим GMail: вы можете рассматривать модули, как независимые единицы функциональности, которые могут и должны существовать сами по себе; возьмём к примеру чат. Скорее всего он основан на своём отдельном модуле чата, но так как этот модуль скорее всего очень сложный, то он вероятно состоит из более мелких вспомогательных модулей. Например, один из таких модулей мог бы отвечать за использование смайликов и он же мог бы использоваться не только в чате, но также и в почте.
В этом и заключается идея нашей архитектуры — если модуль заботится исключительно о том, чтобы уведомить систему об интересующих ее происшествиях, и не волнуется запущены ли другие модули, то система может добавлять, удалять или заменять одни модули, не ломая при этом другие, что было бы невозможно при сильной связанности.
Слабая связанность — необходимое условие для того, чтобы такая идея была возможна. Она делает поддержку модулей проще, удаляя зависимости в коде там, где это возможно. В вашем случае, одни модули должны работать корректно вне зависимости от того в каком порядке загрузились другие модули. Когда слабая связанность реализована эффективно, становится очевидно, как изменения в одной части системы влияют на другие ее части.
В JavaScript есть несколько способов реализации модулей, включая
шаблон «Модуль» и Object Literal (литеральная запись объекта var obj = {};).
Опытные разработчики должно быть уже знакомы с ними. Если это так, то вы можете
пропустить следующую главу и перейти сразу к главе «Модули CommonJS».