Достоинства Namepsaces / Packages


14

Некоторые языки программирования (например, Java и C ++) имеют языковые функции, называемые «пакетами» или «пространствами имен». Насколько полезно иметь пространства имен? Можно пометить функции и классы как принадлежащие некоторой конкретной библиотеке, не используя такую ​​языковую функцию, как SDL (например SDL_BlitSurface()). Разве пространства имен не достаточно полезны, чтобы их стоило иметь? Они полезны в библиотеках, но не в приложениях? Они полезны везде, кроме небольших проектов? Мысли?

Ответы:


16

Разве префиксы имен - это не то же самое, что пространство имен , за исключением того, что это сделано таким образом, что это менее полезно и труднее читать / анализировать? Вопрос не отвечает сам по себе?


Просто добавление префикса в начале имени идентификатора - это не то же самое, что использование языковой функции, такой как пространства имен. Например, в C ++ вы можете сказать, что вы являетесь usingконкретным пространством имен, и тогда вам не нужно ставить префикс в начале идентификаторов в этом пространстве имен.
compman

2
@ user9521 - это моя точка зрения ...
Николь

+1 Одно большое преимущество пространств имен заключается в том, что вы можете пропускать / сокращать префикс, когда он не нужен - в пространстве имен, где определена конкретная вещь, на которую ссылаются using, посредством import xxxxxxxxx as yyy, и т. Д.

1
Поскольку большинство программистов ленивы, вы бы предпочли объявить using SDL;или печатать SDL_*везде?
Берин Лорич

2
+1, но я думаю, что вы действительно имели в виду «менее полезный, более трудный для чтения и не проверенный компилятором».
Ларри Коулман

5

Большинство (все?) Языков с пространствами имен имеют тенденцию быть объектно-ориентированными. Во многих случаях подходит удобочитаемое имя для типа, даже если существует несколько несовместимых реализаций. (это поднимает другие проблемы по объектно-ориентированному повторному использованию, но это не тот вопрос). Например, в Java у вас есть Timer, который используется для фоновых задач пользовательского интерфейса, и Timer, который используется для фоновых приложений (не привязанных к AWT / Swing). Пространство имен позволяет вам иметь эти одноименные объекты, живущие в разных под-API.

Причина появления пространств имен была связана с необоснованной задачей предугадывать, как другие разработчики будут называть свои объекты. C ++ ввел эту концепцию (или, по крайней мере, был первым языком, с которым я познакомился с этой концепцией), и он был полезен, даже несмотря на то, что не было руководящих принципов по наилучшему использованию. Java адаптировала концепцию и добавила некоторые «лучшие практики», которые включали название вашей компании в пространство имен. Таким образом, вам нужно было беспокоиться только о своей собственной компании.

Префикс может стать довольно грязным. Когда вы применяете это? Когда ты не применяешь это? Получают ли префиксы структуры / классы / глобальные методы? Как насчет методов? Как насчет свойств в структуре. Я видел все эти вещи в коде, хотя, к счастью, не все сразу. Пространства имен обеспечивают некоторую предсказуемость для всех этих вопросов и делают его языковой функцией, а не личной «лучшей практикой».


Haskell имеет пространства имен (модули) и не является объектно-ориентированным.
Джереми Хейлер

3

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


1
Тем не менее, в случае конкретного соглашения Java, не у всех есть веб-сайт. Кроме того, если вы когда-нибудь перенесете свою программу с одного веб-сайта на другой (например, Sourceforge на Github), было бы разумно, но неудобно менять пакеты, если другие вещи зависят от вашего кода.
compman

1
Соглашение Java применяется к вашей организации, а не к месту ее размещения. Вы можете просто объявить себя организацией и покончить с этим. Существует также проблема URL-адресов, допускающих символы, которые нельзя использовать в именах пакетов. Но мы не пойдем туда. Так что для вас, просто используйте «me.user9521» в качестве имени вашего пакета, и вы настроены.
Берин Лорич

1
Соглашение не о веб-именах, а о доменных именах. Вы можете иметь домен без веб-сайта.
Дэвид Торнли

1

Пространства имен / Модули / Пакеты полезны для избежания конфликтов имен. То же относится и к префиксам имен, но пространства имен имеют дополнительное удобство - возможность импортировать символы в текущее пространство имен, так что вам не нужно беспокоиться обо всем пространстве имен :: *.

Некоторые языки (например, Python) расширяют эту возможность, позволяя вам импортировать только определенные символы в текущий модуль или импортировать символы под другим именем. Это полезно, если вас интересуют только несколько классов / функций / констант или если некоторые символы конфликтуют с символами в вашем пространстве имен, а некоторые нет.

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.