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

На самом деле я думаю, что обратное именование пакетов доменных имен - одно из самых блестящих соглашений в Java.

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

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

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

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

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

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

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

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

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

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

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

• Его «обратный» характер делает структуру каталогов классов очень узкой на верхнем уровне. Если вы развернете jar, вы увидите каталоги com, org, net и т. д., А затем под каждым из них название организации / компании.

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

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

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

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

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

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

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

oak.lang.Object