Каков предлагаемый способ назвать пакеты Java?

Я видел много примеров, как com.mycompany.someapp. Кажется, это обратная сторона домена. Который на самом деле имеет смысл для меня.

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

Итак, это хорошая практика, чтобы назвать его в соответствии с доменом? Если так, то почему?

9
java naming-conventions

7 ответов

извлечено из ссылки на именование пакета (java Tutorial) в комментарии Андрея: (я не претендую на оригинальность или владение следующим).

наименование

с программистами по всему миру, пишущими классы и интерфейсы с использованием языка программирования Java, вполне вероятно, что многие программисты будут использовать одно и то же имя для разных типов. на самом деле, предыдущий пример делает именно это: он определяет класс Rectangle, когда есть уже класс Rectangle в java.пакет awt. Тем не менее, компилятор позволяет обоим классам иметь одно и то же имя, если они находятся в разных пакетах. Полное имя каждого класса Rectangle включает имя пакета. То есть полное имя класса Rectangle в графическом пакете-graphics.Прямоугольник и полное имя класса Rectangle в java.пакет awt-это java.ОУ.Прямоугольник.

это работает хорошо, если два независимых программиста не используют то же самое название для их пакетов. Что мешает этой проблеме?

Именования

  1. имена пакетов написано строчными буквами чтобы избежать конфликтов с именами классов или интерфейсов.

  2. С используйте [их] обратное доменное имя Интернета, чтобы начать свои имена пакетов-например, com.образец.mypackage для пакета с именем mypackage, созданного программистом на example.com.

  3. имя столкновения, которые происходят внутри одной компании, должны обрабатываться по соглашению внутри этой компании, возможно, путем включения региона или названия проекта после названия компании (например, com.образец.регион.пакета mypackage).

  4. пакетов в самом языке Java начните с java. или javax.

в некоторых случаях имя домена интернета не может быть допустимое имя пакета. Это может произойти, если имя домена содержит дефис или другой специальный символ, если имя пакета начинается с цифры или другого символа, который незаконно использовать в качестве начала имени Java, или если имя пакета содержит зарезервированное ключевое слово Java, такое как "int". В этом случае предлагаемое соглашение должно добавить подчеркивание. Например:

Legalizing Package Names Domain Name   Package Name Prefix
hyphenated-name.example.org            org.example.hyphenated_name
example.int                            int_.example
123name.example.com                    com.example._123name

удачи в кодировании.

8

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

6

Да, это предлагаемое соглашение в спецификация языка Java, раздел 7.7.

Если уникальные имена пакетов не используются, то конфликты имен пакетов могут возникать далеко от точки создания любого из конфликтующих пакетов. Это может создать ситуацию, которую трудно или невозможно разрешить пользователю или программисту. Class ClassLoader может использоваться для изоляции пакетов с одинаковым именем друг от друга в тех случаях, когда пакеты будут иметь ограниченные взаимодействия, но не таким образом, который прозрачен для наивной программы.

вы формируете уникальное имя пакета, сначала имея (или принадлежа к организации, которая имеет) доменное имя интернета, например sun.com - ... Затем вы отменяете это имя, компонент за компонентом, чтобы получить в этом примере com.sun, и используйте это в качестве префикса для имен пакетов, используя соглашение, разработанное в вашей организации для дальнейшего администрирования пакета имена.

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

4

идея использования доменного имени заключается в том, чтобы избежать конфликтов пространств имен в упаковке. Это работает только в том случае, если все следуют конвенции. Так что да, конвенция важна. Тем не менее, если вы никогда не планируете экспортировать свой код в качестве API или предоставлять его третьей стороне, вероятно, есть немного недостатков в использовании любого имени пакета, которое вам нравится.

0

практически говоря, мне это нравится по ряду причин:

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

а также это, это также рекомендуется в JLS. Это не требование, но когда это практически 0 усилий, я бы сделал это, если нет веской причины иначе.

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

0

основная цель состоит в том, чтобы гарантировать уникальность имен пакетов, но если вы никогда не собираетесь выпускать код для других, чтобы использовать, то это, вероятно, не имеет значения, но многое можно сказать о том, чтобы придерживаться Конвенции и беспокоиться о вещах, которые имеют значение. В противном случае наступит день, когда вы поймете, что у вас есть отличная библиотека, которой вы хотите поделиться, вы можете пинать себя за то, что идете против течения.

0

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

общие классы, такие как User или Address будет использоваться несколькими библиотеками, но в конечном итоге в среде выполнения может быть только один класс с определенным именем. (грубо говоря, это не совсем корректно.)

в больших проектах вы, вероятно, будете использовать много внешних библиотек, таких как Apache Commons, Google Guava, Весна, Зимняя Спячка, Терракота. Хорошо, что все эти библиотеки используют собственное пространство имен, чтобы их внутренние классы случайно не конфликтовали.

0