Ist die Java-Paketnamenkonvention fehlerhaft? [geschlossen]

Wir sind alle mit der Java-Konvention zum Umkehren des Domänennamens vertraut. Das heißt www.evilcorp.com, wir würden uns konventionell dafür entscheiden, ihre Java-Pakete zu haben com.evilcorp.stuff.

Ich habe es immer mehr satt. Als kommerzieller Programmierer stelle ich immer wieder fest, dass der Name des Softwarepakets aufgrund eines Rebrandings, einer Übernahme oder Ähnlichem völlig irrelevant ist.

In der Open Source-Welt gibt es weniger Namensänderungen, daher ist dies sinnvoll. Es scheint mir jedoch, dass die Haltbarkeit vieler (kommerzieller / interner) Software-Teile viel länger ist als die der Organisation, die sie herstellt.

Das Problem wird häufig durch Softwareprojekte verschlimmert, bei denen die Marketingabteilung den Namen du jour verwendet, der sich auf ein bestimmtes Projekt bezieht. Ein Name, der sich 3 Monate später ändern wird, damit sich die neuen Kleider des Kaisers frisch und neu anfühlen.

Aus diesem Grund habe ich meistens aufgehört, die Reverse-Domain als Paketnamen zu verwenden. Zugegeben, wenn dies in großem Umfang durchgeführt wird, besteht das Risiko von Namenskollisionen, aber dies wird sicherlich gemindert, indem entweder "eindeutige" Softwarenamen verwendet, generische Wörter vermieden werden oder die umgekehrte Domäne für Projekte verwendet wird, die als Bibliotheken verkauft / veröffentlicht werden sollen .

Andere Gedanken?

Ich zitiere den Rat, den Microsoft für Namespaces (.NET-Pakete) gibt, die nicht die Domainnamen-Konvention haben. Ich denke, es ist auch ein guter Rat für Java-Pakete, da ich nicht glaube, dass ein Domain-Name eine solide und stabile Identität darstellt.

Das allgemeine Format für einen Namespace-Namen lautet wie folgt:

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

Zum Beispiel Microsoft.WindowsMobile.DirectX.

Verwenden Sie ein Präfix für Namespace-Namen mit einem Firmennamen, um zu verhindern, dass Namespaces von verschiedenen Firmen denselben Namen und dasselbe Präfix haben.

Verwenden Sie einen stabilen, versionsunabhängigen Produktnamen auf der zweiten Ebene eines Namespace-Namens.

Verwenden Sie keine Organisationshierarchien als Grundlage für Namen in Namespace-Hierarchien, da Gruppennamen in Unternehmen in der Regel nur von kurzer Dauer sind.

Der Namespace-Name ist ein langlebiger und sich nicht ändernder Bezeichner. Während sich Organisationen weiterentwickeln, sollten Änderungen den Namespace-Namen nicht veralten lassen.

Wenn auch Ihr Firmenname instabil ist, möchten Sie möglicherweise nur mit dem Produktnamen beginnen.

Sie suchen nach einer Lösung für ein anderes Problem: Wie können wir vermeiden, dass Programmierer X und Programmierer Y sich gegenseitig auf den Zehenspitzen begegnen, indem Sie Dateien in dasselbe Paket packen.

Die Option "Domainnamen einfach umkehren" löst dies auf elegante Weise, da Sie sich ziemlich sicher sind, dass X und Y, wenn sie keine Beziehung zueinander haben, nicht denselben Paketnamensraum auswählen.

Die Konvention ist nicht fehlerhaft. Die Leute sind fehlerhaft, wie Sie sich selbst schön illustriert haben.

Ich kann mir zwei Vorteile vorstellen:

1. Es vermeidet Kollisionen zwischen unabhängigen Entwicklern. Eine Domain ist einzigartig. Zwei Personen können zwei verschiedene Projekte gleich benennen, aber eine Domain hat genau einen Eigentümer.
2. Dies erleichtert das Auffinden des Betreuers. Wenn Sie eine Codebasis erben, die eine Open Source-Bibliothek verwendet, ist es besser, sie in einem Paket zu finden, das Ihnen hilft, sie zu finden. Inzwischen spielt es keine Rolle mehr, denn Sie werden es mit Sicherheit googeln können. Aber vor 10 Jahren war das nicht so offensichtlich.

Der umgekehrte Domänenname wurde verwendet, um Namenskollisionen zu vermeiden, falls verschiedene Organisationen in ihren Bibliotheken dieselben Klassennamen verwenden. Es ist eine einfache Lösung und hat natürlich einige Nachteile (z. B. was ist mit Namenskollisionen für Klassen in derselben Organisation?).

Sie sind nicht dazu verpflichtet, es ist eine Konvention, keine Do or Die-Regel. Beispielsweise respektieren einige Java-Programmierer die Java-Code-Konventionen nicht .

Aber ziehen Sie die Alternativen in Betracht. Wie würden Sie zum Beispiel zwei vollqualifizierte Klassennamen für eine LogFactory mögen:

a50e8400_e29b_41d4_a716_446655440000.LogFactory
f47ac10b_58cc_4372_a567_0e02b2c3d479.Logfactory

oder

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

Also, in meinen Gedanken, benutze, was immer du willst, solange es gesunden Menschenverstand und Rücksichtnahme für die Benutzer deiner Bibliothek beinhaltet.

Wenn ich ein neues Projekt beginne, bestehe ich immer auf einem internen und unveränderlichen Namen, den die Marketingmitarbeiter möglicherweise nicht kennen, da nur im Quellcode darauf verwiesen wird. Auf diese Weise muss ich mich nicht um Änderungen des Projektnamens und die Verschmutzung des Namespaces kümmern.

Dieses Szenario passt zu mir, weil der Quellcode normalerweise kein wichtiger Bestandteil des Produkts ist, dh Projekte sind normalerweise proprietäre Closed-Source-Systeme. In Open-Source-Projekten, in denen der Quellcode das Produkt ist, ist dies möglicherweise nicht möglich.