Javaパッケージ名の規則に欠陥はありますか？[閉まっている]

28

私たちは皆、ドメイン名を変えるJavaパッケージ名の慣習に精通しています。つまりwww.evilcorp.com、慣例により、Javaパッケージを使用することを選択しますcom.evilcorp.stuff。

ますます私はこれにうんざりしています。商用プログラマーとして、ソフトウェアのパッケージ名はブランドの変更、買収などのために完全に無関係であるということに何度も遭遇します。

オープンソースの世界では名前の変更が少ないので、理にかなっています。しかし、多くの（商用/内部）ソフトウェアの保存期間は、それらを作成する組織の保存期間よりもはるかに長いようです。

この問題は、ソフトウェアプロジェクトがマーケティング部門を率いて、特定のプロジェクトを指すdu duという名前を使用することで、さらに悪化することがよくあります。皇帝の新しい服に新鮮で新しい感じを与えるために、3か月後に必ず変更される名前。

このため、逆ドメインをパッケージ名として使用することをほとんどやめました。確かに、これが大規模に行われた場合、名前の衝突のリスクがありますが、「ユニークな」ソフトウェア名を使用するか、一般的な言葉を避けるか、ライブラリとして販売/リリースされるプロジェクトにリバースドメインを使用することで確実に軽減されます。

他の考え？

java naming

— マーティン・アルゲステン
ソース

2

We're all familiar with the Java package name convention of turning the domain name around.-えーと、いや... ...）

— ハンニバルレクター博士

8

@dr Hannibal Lecter：非常に簡単です。Java（サイトJava.com）はパッケージに名前を付けますcom.java.etc.etc。Apache（Apache.orgサイト）はパッケージに名前を付けますorg.apache.etc.etc。パターンが表示されます。

— -doppelgreener

3

@drハンニバルレクター：Cf。docs.oracle.com/javase/tutorial/java/package/namingpkgs.html

— user359996

1

「オープンソースの世界では名前の変更は少ない」-問題があるとしても、現在githubにあるプロジェクトをよく見かけますが、パッケージ名からnet.sourceforge.xxxまたはcomの逆になっていることがわかります。 googlecode.xxx

— nafg

@nafg-右。特定の企業（sourceforgeやgithubのようなものを提供しているのかどうか）を特定の企業と必ずしも結び付けたくないため、最近作業を開始するオープンソースプロジェクトに自分のドメイン名を登録する傾向があるのはこのためですサービス、またはそれを開発するための元の動機を提供した私の会社のようなもの）。それはそれ自身のものになるために自由である必要があります。

— ジュール

23

ドメイン名の規則がないMicrosoftが名前空間（.NETのパッケージ）に対して提供するアドバイスを引用します。ドメイン名は堅実で安定したアイデンティティを表すとは思わないので、Javaパッケージにも良いアドバイスだと思います。

名前空間名の一般的な形式は次のとおりです。

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

たとえば、Microsoft.WindowsMobile.DirectX。

名前空間名の前に会社名を付けて、異なる会社の名前空間が同じ名前とプレフィックスを持つことを防ぎます。

ネームスペース名の第2レベルでは、バージョンに依存しない安定した製品名を使用してください。

企業内のグループ名は短命になる傾向があるため、名前空間階層の名前の基礎として組織階層を使用しないでください。

名前空間名は、永続的で不変の識別子です。組織が進化しても、名前空間の名前を廃止して変更するべきではありません。

会社名でさえ不安定な場合は、製品名から始めたい場合があります。

— アロン・グララネク
ソース

3

別の会社があなたと同じ名前の場合、マイクロソフトは何を推奨しますか？

25

@Thorbjørn-訴訟

— -RevBingo

9

@Thorbjørn：ドメインとは異なり、名前空間は誰にも所有されておらず、所有できません。コードの論理的な区分または分類にすぎません。あなたと他の会社との衝突の可能性はゼロに近づきます。ただし、他の会社が偶然同じ技術でソフトウェアを開発し、同様の製品を提供している場合を除きます。その場合、あなたがあなたの会社と同じ名前を持つ競合会社を持つことに大丈夫でない限り、私はRebBingoの提案を受け入れます。

— アロングラネネク

4

@Thorbjørnの答えで指摘されているように、Java命名規則が解決する問題は、恒常性を保証するのではなく、一意性を保証することです。マイクロソフトの規約ではどちらも保証されていないことに注意してください。

— ユーザー359996

4

@ user359996：私が言ったように、普遍的な一意性が解決が必要な問題である理由がわかりません。相互に排他的なコードベース全体で名前を一意にする必要があるのはなぜですか？また、ドメイン名の所有権が変わる可能性があるため、Javaのスタイルはそれを保証しません。jUtils.comを所有する開発者は、多くのユーザーが使用するcom.jutils。*ライブラリを開発し、それから人気のある別のcom.jutils。*ライブラリを開発する完全に異なる開発者に自分のドメインを販売できます。既存のライブラリ。

— アロングラネネク

15

別の問題の解決策を見ています。つまり、同じパッケージにファイルを入れることでプログラマーXとプログラマーYが互いの足指を踏まないようにする方法です。

「ドメイン名を逆にするだけ」でこれをエレガントな方法で解決します。XとYが無関係である場合、同じパッケージ名前空間を選択しないことが確実であるためです。

+1「別の問題の解決策を見ています。」

— ユーザー359996

10

慣習に欠陥はありません。あなたがうまく自分自身を説明したように、人々は欠陥があります。

私は2つの利点を考えることができます：

独立した開発者間の衝突を回避します。ドメインは一意です。2人のユーザーが2つの異なるプロジェクトに同じ名前を付けることができますが、ドメインには1人の所有者しかいません。
メンテナーを見つけやすくなります。何らかのオープンソースライブラリを使用するコードベースを継承する場合、それを見つけるのに役立つパッケージに入れる方が良いでしょう。今ではそれは本当に重要ではありません。なぜなら、あなたはそれをグーグルで確実に検索できるからです。しかし、10年前、これはそれほど明白ではありませんでした。

— back2dos
ソース

7

異なる組織がライブラリで同じクラス名を使用する場合の名前の衝突を避けるために、逆ドメイン名が使用されました。それは簡単な解決策であり、オフコースにはいくつかの欠点があります（たとえば、同じ組織内のクラスの名前の衝突はどうでしょうか？）。

あなたはそれを使用する義務はありません、それは慣習であり、死ぬルールではありません。たとえば、一部のJavaプログラマーはJava Code Conventionsを尊重しません。

しかし、代替案を検討してください。たとえば、LogFactoryの2つの完全修飾クラス名をどのように使いますか。

a50e8400_e29b_41d4_a716_446655440000.LogFactory
f47ac10b_58cc_4372_a567_0e02b2c3d479.Logfactory

または

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

したがって、私の考えでは、常識とライブラリのユーザーへの配慮が含まれている限り、好きなものを使用してください。

4

新しいプロジェクトを開始するとき、私は常に、マーケティング担当者がソースコードでのみ参照されるため、知らないかもしれない内部の不変の名前を主張します。そうすれば、プロジェクト名の変更や名前空間の汚染を心配する必要がありません。

ソースコードは通常製品の重要な部分ではないため、このシナリオは私に合います。つまり、プロジェクトは通常クローズドソースの専有システムです。ただし、ソースコードが製品であるオープンソースプロジェクトでは、これは実行不可能な場合があります。

— スウェコ
ソース