web-dev-qa-db-ja.com

Javaパッケージ名の規約に欠陥がありますか？

ドメイン名を変更するJavaパッケージ名の規則）はすべて知っています。つまり、www.evilcorp.comは、慣例により、Javaパッケージcom.evilcorp.stuff。

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

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

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

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

他の考え？

javanaming
28
Martin Algesten

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

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

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

例えば、 Microsoft.WindowsMobile.DirectX。

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

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

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

名前空間名は、長期間有効で変更されない識別子です。組織が進化しても、変更によってネームスペース名が古くなることはありません。

会社名でさえ不安定な場合は、製品名から始めることをお勧めします。

23
Allon Guralnek

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

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

15
user1249

大会に欠陥はありません。あなたが自分自身をうまく描写したように、人々は欠陥があります。

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

  1. 独立した開発者間の衝突を回避します。ドメインは一意です。 2人が2つの異なるプロジェクトに同じ名前を付けることはできますが、ドメインの所有者は1人だけです。
  2. メンテナーを見つけやすくなります。オープンソースライブラリを使用するコードベースを継承する場合は、見つけやすいパッケージにすることをお勧めします。あなたは間違いなくそれをググることができるので、今ではそれは本当に問題ではありません。しかし、10年前、これはそれほど明白ではありませんでした。
10
back2dos

別の組織がライブラリで同じクラス名を使用する場合の名前の衝突を回避するために、逆ドメイン名が使用されました。これは単純なソリューションであり、オフコースにはいくつかの欠点があります（たとえば、同じ組織内のクラスの名前の衝突はどうですか？）.

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

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

a50e8400_e29b_41d4_a716_446655440000.LogFactory
f47ac10b_58cc_4372_a567_0e02b2c3d479.Logfactory

または

org.Apache.commons.logging.LogFactory
com.evilcorp.logging.LogFactory

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

7
user7197

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

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

4
SWeko