9

私は Java SE の学習曲線に近づきつつあり、パッケージ名の通常の Java 規則に問題はありません。com.example.library_name_here.package_name_here

を除外する。

よく知られているいくつかのパッケージで、これを順守していないことに気づきました。

  • Jライン:jline.*
  • ジェイコブ: ( jacob.comcom.jacob.*はありません)
  • JNA : com.sun.jna.*(サイトの免責事項には、注: パッケージ名 (com.sun.jna) が別の意味を含んでいる可能性がありますが、Sun はこのプロジェクトのスポンサーではないと書かれています。)

だから私は疑問に思っています、通常の逆ドメイン名の慣習が壊れる例はありますか?それを回避する良い方法はありますか? 私が考えることができる唯一のケースは、ドメイン名の所有権に関する問題です (たとえば、プロジェクトのホスティング/ドメイン名を変更したり、ドメインに対して「不法占拠者の権利」を持つよく知られたパッケージが既に存在する場合や、ドメインの所有権が実行されている場合など)。アウト & 他の誰かがそれをスナップします)。

編集: 会社のドメイン名を使用していて、買収またはスピンオフした場合、パッケージ名はどうすればよいですか? それらを同じままにするか、名前を変更しますか？(パッケージを参照するコンパイルされたクラスが失われるという観点から、名前の変更は悪いと思います)

4

6 に答える 6

12

命名規則です。パッケージ名がドメイン名にマップされるという実際の要件や期待さえありません。

于 2009-01-07T16:24:08.347 に答える
5

一般的な考え方として、2 つの組織が同じドメインを所有することはないため、ドメイン名をパッケージの一部として使用することで名前空間の競合がなくなります。ただし、これは推奨事項にすぎません。

パッケージを sun 名前空間に置くのには十分な理由があります。パブリック API の実装を提供している場合、多くの場合、API の名前空間にクラスを実装する必要があります。

于 2009-01-07T16:39:22.233 に答える
3

Java の学習曲線を上っていく場合は、探しているクラスを簡単に見つけられるように、パッケージ構造を明確にすることについてもっと心配します。

于 2009-01-07T17:21:28.793 に答える
2

パッケージは、さまざまなエンティティによって構築されたコンポーネント間のあいまいさと衝突を回避するために使用されます。規則に従っている限り、パッケージの名前空間の一部を不正に使用する人がいない限り、他の人が何を使用したかについて心配する必要はありません。

于 2009-01-07T18:15:06.500 に答える
1

唯一重要なこと (IMHO) は、パッケージ名の部分が重要度によって「ソート」されていることです。つまり、gui.myprog、util.myprog、main.myprog ではなく、myprog.gui、myprog になることです.util、および myprog.main です。パッケージ名が実際にトップレベル ドメインで始まり、その後にドメイン名が続くかどうかは、私には関係ありません。

于 2009-01-07T16:23:06.523 に答える
1

パッケージ名の一部として言語キーワードを使用することはできません。これは、ドメイン名の規則を適用できないもう 1 つのケースです - LONG Building Technologiesには不運です

しかし、慣習は単なる慣習であり、それが存在するほとんどの唯一の理由は、異なるプロジェクトが誤って同じパッケージ名を選択する可能性を最小限に抑えるためです。守れなくても、大した問題ではありません。

于 2009-01-07T16:24:44.867 に答える