Чи є помилковим умова назви пакету Java? [зачинено]

Ми всі знайомі з умовами імені пакета Java щодо перетворення доменного імені. Тобто www.evilcorp.com, за умовою, вони вирішили мати свої пакети java com.evilcorp.stuff.

Все частіше я набридаю цим. Як комерційний програміст, я знову і знову стикаюся з тим, що назва програмного пакета абсолютно не має значення через певну ребренду, придбання чи подібне.

У світі відкритих джерел менше змін імен, тому там є сенс. Однак мені здається, що термін зберігання багатьох програм (комерційного / внутрішнього) програмного забезпечення набагато довший, ніж у організації, яка їх виготовляє.

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

Через це я здебільшого перестала використовувати зворотний домен як назву пакета. Зрозуміло, що якщо це робиться у великих масштабах, існує ризик зіткнень з іменами, але, безумовно, це зменшується, використовуючи "унікальні" імена програмного забезпечення, уникаючи загальних слів, або використовуючи зворотний домен для проектів, призначених для продажу / випуску як бібліотеки .

Інші думки?

Я процитую поради, які Microsoft дає щодо просторів імен (пакетів .NET), у яких немає домовленостей щодо доменних імен. Я думаю, що це корисна порада і для Java-пакетів, оскільки я не вірю, що ім'я домену являє собою міцну і стабільну ідентичність.

Загальний формат імені простори імен такий:

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

Наприклад, Microsoft.WindowsMobile.DirectX.

Виконайте префіксні імена з іменем компанії, щоб у просторів імен різних компаній не було одного і того ж імені та префікса.

Використовуйте стабільну, незалежну від версії назву продукту на другому рівні імені простору імен.

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

Ім’я простору імен є довговічним і незмінним ідентифікатором. По мірі розвитку організацій зміни не повинні робити назву простору імен застарілим.

Якщо навіть назва вашої компанії нестабільна, ви можете просто почати з назви продукту.

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

"Просто переверніть своє доменне ім'я" вирішуйте це елегантно, оскільки ви впевнені, що якщо X і Y не пов'язані між собою, вони не виберуть однаковий простір імен пакета.

Конвенція не є хибною. Люди недоліки, як ви чудово проілюстрували себе.

Я можу подумати про дві переваги:

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

Тож, по-моєму, використовуйте все, що вам подобається, якщо це включає здоровий глузд і увагу до користувачів вашої бібліотеки.

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

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