Вопрос по namespaces, javascript – Почему пространства имен считаются плохой практикой в JavaScript? [закрыто]

4

Мне сказали, что пространства имен не должны использоваться, так как они "загрязняют"; глобальный охват. Интересно, какие есть альтернативы?

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

Если пространства имен - это плохая практика, на ум приходит пара вопросов:

Why is this bad practice? What's the scope of this declaration (web applications / dynamic websites / static websites etc.)? What are the alternatives?

This question is a result of a discussion started on пост о преимуществах использования exte.js.

И я всегда думал, что пространства имен именно дляnot загрязняя глобальную сферу ... (-> они естьgood). Felix Kling
@Raynos: Конечно, каждое пространство имен верхнего уровня создает символ в глобальной области видимости ... но как бы вы получили доступ к внешней библиотеке, если бы она не была? Felix Kling
Да, у кого-то есть это задом наперед. Dave Newton
Пространства имен @FelixKling по-прежнему загрязняют глобальный охват. Вам никогда не нужны глобальные токены в JavaScript. Любой, кто их использует, делает это неправильно. Raynos
@FelixKling пользовательские загрузчики модулей с использованием замыканий. Библиотеки не должны предоставлять глобальные токены, они должны предоставлять свои модули в стандартном формате, таком как AMD или commonJS, а загрузчики модулей должны извлекать эти модули и обрабатывать межмодульные зависимости. Это можно сделать с нулевыми глобальными токенами, созданными пользователем (даже избегая временных глобальных токенов) Raynos

Ваш Ответ

4   ответа
8

why is this bad practice?

пространства имен сами по себе являются плохими, потому что это ненужная концепция.

Наличие объектов со свойствами и методами приемлемо. Также хорошо иметь «модуль»; токен, который похож на «пространство имен»; но вместо этого смысл в том, что у вас есть один «модуль» токен для файла, который содержит все ваши свойства и методы. Это отличается от "пространства имен" потому что он создается / изменяется только в одном файле и не отображается как глобальный токен.

what's the scope of this declaration (web applications / dynamic websites / static websites etc.)?

Все ECMAScript, никогда не создавайте новые глобальные токены

what are the alternatives?

Вместо того, чтобы иметь пространства имен, вы должны отдать предпочтение множеству & quot; файлов локальных & quot; жетоны. Это означает, что каждый файл / & quot; модуль & quot; следует заключить в замыкание, и у вас должен быть доступ к нескольким локальным переменным внутри этого замыкания.

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

Примеры нулевых глобальных загрузчиков модулей

Дальнейшее чтение:

Здесь нет нужды глобалов. Вы можете ввести токеныdefine а такжеrequire в модули с помощью других, а не глобальных токенов
Нужны только две глобалы: AMDdefine а такжеrequire функции. ;)
Рейнос, я знаю, что вы достаточно опытны, чтобы иметь смысл, но вам не хватает фактического примера кода, демонстрирующего то, о чем вы говорите (см. Пункт 3 в вопросе).
@JaredFarrish все эти файлы завернуты для вас. Завершение каждого отдельного файла в закрытие ужасно, когда задача сборки может сделать это за вас. Это & quot; файл локальный & quot; токены или «модульные токены»
Хорошо, кто-то должен копаться в этом и найти код, который делает вашу точку зрения? Первый думаю, что яclicked on показывает пять глобальных переменных.
3

Я не могу себе представить, почему пространство имен было бы плохо. Если нет некоторого определения пространства имен, специфичного для JavaScript, о котором я не знаю.

В настоящее время я работаю над небольшой библиотекой, и все окружено одним объектом верхнего уровня (пространством имен?). Я не помещаю что-либо в окно или внутренние типы; если вам нужно что-то из моей библиотеки, это доступно вkilo объект.

Мне, имеющему это «пространство имен»; этоgood попрактикуйтесь, так как это позволяет мне очень быстро узнать, вызываю ли я метод в моей библиотеке. Нет необходимости переопределятьwindow.alert метод, который может привести к другой загруженной библиотеке на странице; просто используйтеkilo.alert для настроенной версии (это надуманный пример, но я надеюсь, что это важно).

Вам не нужно "пространство имен"; Чтобы узнать, вызываете ли вы метод из библиотеки, вы просто манипулируете объектами и токенами, предоставляемыми этой библиотекой.
Я думаю, что нам нужно более четкое определение пространства имен. У JavaScript их нет, но мы говорим о них так, как будто они на самом деле являются частью языка. На самом деле, я просто использую родительский объект для своей библиотеки. Пространство имен на самом деле не вещь в JavaScript; даже то, что здесь называется пространством имен, на самом деле является просто цепочкой объектов.
1

& Quot; Пространства имен & Quot; в JavaScript действительно просто объекты с именованными свойствами. В других ОО-языках (например, C ++, C # и т. Д.), Я не думаю, что вы захотите следующее:

C # -

public static class MyAppName {}
public static class MyArea {}
public static class MySubArea {}

public static class Test {
  public string Property1 { get { return "test"; }}
}

Просто так вы можете иметь

MyAppName.MyArea.MySubArea.Test.Property1;

Таким образом, в основном, поскольку JS на самом деле не поддерживает пространства имен, люди придумали хак для имитации пространств имен, который затем делает его «крутым». написать что-то вроде:

myAppSpace.mySubArea.myObject = blah...
Как правило, плохая идея (не говоря уже о плохой форме) ссылаться на «реальный мир». а затем включите код с другого языка, чтобы сделать вашу точку зрения.
@Raynos - я знаю, в чем смысл, мы говорим о JS. И это C #.
Вы, вероятно, правы ... :)
@JaredFarrish Я полагаю, он пытается проиллюстрировать, что это "пространство имен". Концепция, портированная на другой язык, такой как C #, также генерирует уродливый и глупый код.
2

Лично я думаю, что люди, которые говорят, что вы должныnever загрязнение глобальной области не в состоянии правильно определить «загрязнение». Вы можете увидеть это в некоторой степени в роднойMath объект, например. Любой другой язык программирования, который я знаю, имеет все математические функции как простые функции, но JS не делает этого. Однако, если вы доведите это до крайности, простое окно предупреждения будетcore.dialog.alert вместо этого, например.

Мне нравится заключать весь мой код в замыкания, чтобы поддерживать переменные в чистоте. Тем не менее, мой основной файл сценария JS определяет кучу служебных функцийin the global scopeтакой как обычайAlert(), или жеAJAX()или другие широко используемые функции. Если я собираюсь использовать их часто, я не хочу, чтобы файл был заполнен вызовами пространства имен. И поскольку я определяю все свои переменные в замыканиях, нет риска случайной перезаписи функций (я мог бы сделать это в самом замыкании, но это не оказало влияния на глобальную область видимости).

В целом, пространства имен переоценены. Просто напишите свой код и не плачь по каждомуwindow имущество.

Ваши рекомендации людям использовать глобальные переменные, это плохая практика.
Другая проблема, связанная с глобальными переменными, заключается в том, что они глобальны, и все, что может прочитать / изменить / повредить / изменить / вообще связать с ними. Это похоже на концепцию, согласно которой вы не должны встраивать запросы SQL непосредственно в представления в своих веб-приложениях на стороне сервера. В основном глобалы нарушают разделение проблем
Пространство имен и другие методы гораздо более полезны в определенных средах, где у вас могут быть многоуровневые библиотеки, которые могут конфликтовать. Например, JIRA использует пространства имен, чтобы размещать такие вещи, как jQuery, за пределами области окна, но существует значительное количество библиотек, которые он использует, так что это имеет смысл. В целом, никто еще не высказал мнениеwhy вам следует избегать глобальных переменных в JS, так как они легко перезаписываются любым другим сценарием, и в этом случае могут возникнуть проблемы. Так что имеет смысл быть осторожным, не раздумывая об этом в целом.

Похожие вопросы