Мы все знакомы с соглашением об именах пакетов Java, которое заключается в переворачивании доменного имени. Т.е. www.evilcorp.com, по соглашению, решил иметь свои пакеты Java com.evilcorp.stuff.
Всё сыт по горло этим. Как коммерческий программист, я снова и снова сталкиваюсь с тем, что название программного пакета совершенно не имеет значения из-за какого-то ребрендинга, приобретения или тому подобного.
В мире open source меньше имен, так что это имеет смысл. Однако мне кажется, что срок годности многих (коммерческих / внутренних) программных продуктов намного дольше, чем у организации, производящей их.
Проблема часто усугубляется программными проектами, когда отдел маркетинга начинает использовать имя du jour, которое они используют для обозначения определенного проекта. Имя, которое непременно изменится через 3 месяца, чтобы новая одежда императора стала свежей и новой.
Из-за этого я в основном перестал использовать обратный домен в качестве имени пакета. Конечно, если это делается в больших масштабах, существует риск конфликтов имен, но, безусловно, это можно уменьшить, используя «уникальные» имена программного обеспечения, избегая общих слов, или используя обратный домен для проектов, предназначенных для продажи / выпуска в качестве библиотек. ,
Другие мысли?
We're all familiar with the Java package name convention of turning the domain name around.- гм .. нет, мы не ... :)com.java.etc.etc. Apache (на сайте Apache.org) называет свои пакетыorg.apache.etc.etc. Вы видите образец.Ответы:
Я собираюсь процитировать совет, который Microsoft дает для пространств имен (пакетов .NET), которые не имеют соглашения о доменном имени. Я думаю, что это хороший совет и для пакетов Java, так как я не верю, что доменное имя представляет собой твердую и стабильную идентичность.
Если даже название вашей компании нестабильно, вы можете начать с названия продукта.
источник
Вы смотрите на решение другой проблемы, а именно, как избежать того, чтобы программист X и программист Y давили друг другу на ноги, помещая файлы в один пакет.
«Просто поменяйте местами ваше доменное имя» решите это элегантным способом, так как вы вполне уверены, что если X и Y не связаны, они не выберут одно и то же пространство имен пакета.
источник
Конвенция не является ошибочной. Люди с недостатками, как вы хорошо проиллюстрировали сами.
Я могу думать о 2 преимуществах:
источник
Обратное доменное имя использовалось, чтобы избежать конфликтов имен в случае, если разные организации используют одинаковые имена классов в своих библиотеках. Это простое решение, и у него есть некоторые недостатки (например, как насчет коллизий имен для классов в одной организации?).
Вы не обязаны его использовать, это соглашение, а не правило «делай или умри». Например, некоторые программисты на Java не уважают соглашения о коде Java .
Но рассмотрим альтернативы. Как бы вы, например, хотели два полностью определенных имени класса для LogFactory:
или
Поэтому, в моих мыслях, используйте все, что вам нравится, если это включает в себя здравый смысл и внимание пользователей вашей библиотеки.
источник
Когда я начинаю новый проект, я всегда настаиваю на внутреннем и неизменном имени, которое маркетологи могут знать или не знать, так как оно будет упоминаться только в исходном коде. Таким образом, мне не нужно беспокоиться об изменении имени проекта и загрязнении пространства имен.
Этот сценарий мне подходит, потому что исходный код обычно не является важной частью продукта, то есть проекты, как правило, являются закрытыми, проприетарными системами. Однако в проектах с открытым исходным кодом, где исходный код является продуктом, это может оказаться невозможным.
источник