Является ли соглашение об именах пакетов Java некорректным? [закрыто]

Мы все знакомы с соглашением об именах пакетов Java, которое заключается в переворачивании доменного имени. Т.е. www.evilcorp.com, по соглашению, решил иметь свои пакеты Java com.evilcorp.stuff.

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

В мире open source меньше имен, так что это имеет смысл. Однако мне кажется, что срок годности многих (коммерческих / внутренних) программных продуктов намного дольше, чем у организации, производящей их.

Проблема часто усугубляется программными проектами, когда отдел маркетинга начинает использовать имя du jour, которое они используют для обозначения определенного проекта. Имя, которое непременно изменится через 3 месяца, чтобы новая одежда императора стала свежей и новой.

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

Другие мысли?

Я собираюсь процитировать совет, который Microsoft дает для пространств имен (пакетов .NET), которые не имеют соглашения о доменном имени. Я думаю, что это хороший совет и для пакетов Java, так как я не верю, что доменное имя представляет собой твердую и стабильную идентичность.

Общий формат для имени пространства имен выглядит следующим образом:

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

Например, Microsoft.WindowsMobile.DirectX.

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

Используйте стабильное, независимое от версии имя продукта на втором уровне имени пространства имен.

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

Имя пространства имен является долгоживущим и неизменным идентификатором. По мере развития организаций изменения не должны делать имя пространства имен устаревшим.

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

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

«Просто поменяйте местами ваше доменное имя» решите это элегантным способом, так как вы вполне уверены, что если X и Y не связаны, они не выберут одно и то же пространство имен пакета.

Конвенция не является ошибочной. Люди с недостатками, как вы хорошо проиллюстрировали сами.

Я могу думать о 2 преимуществах:

1. Это позволяет избежать столкновения между независимыми разработчиками. Домен уникален. Два человека могут называть два разных проекта одинаково, но домен имеет ровно одного владельца.
2. Это облегчает поиск сопровождающего. Если вы наследуете кодовую базу, которая использует какую-то библиотеку с открытым исходным кодом, она должна быть в пакете, который поможет вам ее найти. К настоящему моменту это не имеет большого значения, потому что вы наверняка сможете его найти. Но 10 лет назад это было не так очевидно.

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

Вы не обязаны его использовать, это соглашение, а не правило «делай или умри». Например, некоторые программисты на Java не уважают соглашения о коде Java .

Но рассмотрим альтернативы. Как бы вы, например, хотели два полностью определенных имени класса для LogFactory:

a50e8400_e29b_41d4_a716_446655440000.LogFactory
f47ac10b_58cc_4372_a567_0e02b2c3d479.Logfactory

или

org.apache.commons.logging.LogFactory
com.evilcorp.logging.LogFactory

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

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

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