Вы действительно используете свой обратный домен для именования пакетов в java?

Ответ 1

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

Эта схема делает две важные вещи:

• Весь ваш код содержится в пакетах, с которыми никто не столкнется. Вы владеете своим доменным именем, поэтому оно изолировано. Если бы у нас не было этого соглашения, у многих компаний был бы пакет "утилит", содержащий классы типа "StringUtil", "MessageUtil" и т.д. Они бы быстро столкнулись, если вы пытались использовать код другого пользователя.

• "Реверсивный" характер этого делает макет класса-каталога очень узким на верхнем уровне. Если вы развернете банку, вы увидите "com", "org", "net" и т.д., Затем под каждым из них имя организации/компании.

Обычно мы не расширяем банки, но в ранней разработке Java это было важно, потому что люди использовали расширенные структуры dir для апплетов.

Однако теперь это хорошо, поскольку структуры исходного кода исходного кода имеют ощущение "сверху вниз". Вы переходите от большинства общих (com, org, net...) к менее общим (название компании) к более конкретным (имя проекта/продукта/lib)

Ответ 2

Я действительно думаю, что именование имен обратного доменного имени является одним из наиболее ярких соглашений в Java.

Ответ 3

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

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

Ответ 4

Я думаю, что это сильно зависит от того, какое программное обеспечение написано. Например, я разрабатываю внутренние системы для небольшой компании, поэтому я выбираю:

[company].[project].[sub].xyz(.abc)

Где sub обычно один из client, common и server. Если бы я работал в (коммерческой) компании-разработчике программного обеспечения, я бы гораздо больше не хотел использовать бит project, потому что, вероятно, то, что приложение было вызвано при запуске проекта и что оно называется, когда оно закончилось, - это два совершенно разные вещи! Здесь:

oak.lang.Object

Ответ 5

Да, я использую обратный домен для начала пакета, а затем другую административную информацию (проекты, отделы и т.д.). Использование домена минимизирует вероятность столкновений между проектами поставщиков/компаний/FOSS. Мой пакет "данных" не столкнется с другим пакетом данных компании благодаря домену.

Я также использовал соглашение о выводе tld для внутренней работы или классов, которые не предназначены для внешнего использования (возможно, недокументированные библиотеки поддержки и т.д.). Обычно это дает понять другим разработчикам, что к блоку кода могут применяться разные правила или политики.

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

Ответ 6

Я делаю это для всех моих проектов, я даже использовал его для своих приложений .NET для пространств имен.

Ответ 7

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

Ответ 8

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

Ответ 9

Он очень полезен и скопирован другими (например, XML-схемой).

Он полезен в "большом" (учитывая WWW), но, возможно, более того, в разных отделах (т.е. в малом). Это может показаться раздутым для небольших проектов, но оно действует как страхование: оно там, когда оно вам понадобится позже.