Каково значение обратного доменного имени для структуры пакета Java
Почему мы используем обратное доменное имя как com.something. или org.something. структура для пакетов Java? Я понимаю, что это вводит своего рода уникальность, но почему нам нужна эта уникальность?
6 ответов
Глобально уникальные имена пакетов позволяют избежать конфликтов имен между библиотеками из разных источников. Вместо создания новой центральной базы данных глобальных имен используется реестр доменных имен. Из JLS:
Предлагаемое соглашение для создания уникальных имен пакетов - это просто способ совмещения соглашения об именах пакета поверх существующего , широко известный реестр уникальных имен вместо создания отдельного реестра для имен пакетов.
О том, почему мы делаем это наоборот: представьте, что у вас есть два важных пакета, пакет учета и пакет графики. Если вы указали их в «прямом» порядке:
accounting.mycompany.org
graphics.mycompany.org
Тогда это означает, что существует основной пакет бухгалтерский учет , подраздел которого предназначен для mycompany , а подраздел этот пакет называется пакетом org , который вы фактически используете. Однако вам нужно следующее:
org.mycompany.accounting
org.mycompany.graphics
Это имеет больше смысла. Из всех пакетов от организаций ( org ) вы посмотрите, в частности, на mycompany , и у него есть два подпакета, бухгалтерия и графика шт.
Уникальность необходима для загрузки класса.
Это помогает избежать конфликтов имен. Если есть классы с таким же именем пакета и именем класса, при попытке загрузить классы произойдет столкновение.
Обычно это происходит, если существует несколько библиотек (jar), содержащих классы с одинаковыми именами.
См. Также this .
Вам нужна уникальность, если вам может потребоваться интегрировать свой код со сторонним программным обеспечением или предоставить его кому-то еще для интеграции. Если вы не следуете правилам, вы увеличиваете риск того, что в какой-то момент у вас возникнет конфликт именования классов, и вам придется переименовать множество классов, чтобы решить эту проблему. Или, что еще хуже, вашим клиентам придется переименовывать код.
Это также применимо, когда код создается как часть различных проектов в организации.
Как вы говорите, обратное имя домена в качестве имени базового пакета обеспечивает уникальность. Предположим, две компании с DN example.com и example.org определяют класс Employee в своей структуре. Теперь, если вы используете обе структуры, вы не сможете точно определить, какого сотрудника вы хотите использовать в своем коде, но если они определены в пакетах com.example и org.example соответственно, вы можете указать компилятору / JVM, к какому классу вы относитесь. ссылаясь на. Если уникальные пакеты не определены, вы получите ошибки компиляции или ошибки времени выполнения, например если вы используете класс сотрудника com, но класс сотрудника организации загружается первым из пути к классам, вы получите ошибку времени выполнения, поскольку два класса сотрудников могут иметь разную структуру.
Как вы сказали, она привносит уникальность, что особенно необходимо при работе со сторонним кодом. Например, представьте, что вы используете библиотеку, которую я создал. Я использую пакет "foo" и имею там класс с именем Bar. Если вы также используете пакет с именем "foo" и у вас есть класс с именем Bar, это означает, что ваша реализация будет переопределять мою реализацию Bar, делая мою реализацию недоступной. С другой стороны, если бы мой пакет был "com.mydomain.foo" и у меня там был бы класс Bar, то вы могли бы свободно использовать имя Bar в одном из своих классов, и оба класса все еще могли бы быть уникально идентифицированы и использоваться отдельно.
Зачем использовать обратное доменное имя в качестве имени пакета? Я думаю, это просто соглашение, чтобы убедиться, что все используют уникальное пространство имен, поскольку вы не должны использовать чужой домен в имени своего пакета.