ずっと前から、Java では、パッケージの命名のために所有するドメインを逆にするのはばかげていて扱いにくいと思っていました。
プロジェクトでパッケージの命名に使用するものはどれですか?
ずっと前から、Java では、パッケージの命名のために所有するドメインを逆にするのはばかげていて扱いにくいと思っていました。
プロジェクトでパッケージの命名に使用するものはどれですか?
規則が存在する理由を理解すれば、ばかげたことやぎこちなく感じることはまったくないはずです。
このスキームは、次の 2 つの重要なことを行います。
すべてのコードは、他の誰も衝突しないパッケージに含まれています。ドメイン名はあなたが所有しているため、分離されています。この規則がなければ、多くの企業が「ユーティリティ」パッケージを使用し、「StringUtil」、「MessageUtil」などのクラスが含まれていました。他の誰かのコードを使用しようとすると、これらはすぐに衝突してしまいます。
その「逆」の性質により、トップレベルでクラスディレクトリのレイアウトが非常に狭くなります。jar を展開すると、「com」、「org」、「net」などのディレクトリが表示され、それぞれの下に組織/会社名が表示されます。
(2021 年に追加) これは、このタイプのパッケージ命名がビルド中に推移的に取り込まれ、名前が一意でない場合に簡単に競合する可能性があるサードパーティ ライブラリに使用される現在、さらに重要です。誰もが同じ慣習に従えば、偶発的な衝突はありません。
(2021 年に追加) アプリ ストアのアプリケーション ID にも同じ命名規則を使用して、一意性を確保できます。
通常は jar を展開しませんが、初期の Java 開発では、アプレットに展開されたディレクトリ構造を使用していたため、これは重要でした。
ただし、ソース コードの dir 構造が非常に「トップダウン」な感じになっているので、これは今では良いことです。最も一般的なもの (com、org、net...) から一般的ではないもの (会社名)、より具体的なもの (プロジェクト/製品/ライブラリ名) へと進みます。
逆ドメイン名パッケージの命名は、Java で最も優れた規則の 1 つだと思います。
それが単なる内部プロジェクトであり、コードが再利用される可能性が低い場合は、通常、短くてわかりやすい名前を付けます。
ただし、コードを外部で使用したり、別のプロジェクトで再利用したりする場合は、逆ドメイン スキームを使用する傾向があります。パッケージ名が衝突しないようにします。
私はそれがかなりばかげていると思います。コム。part は実際には 4 文字しか追加しません。また、アセンブリ・プロジェクト名に会社名を使うのも間違っていると思います。私は、他の会社と合併したり、単に名前を変更したりした場所であまりにも多く働いてきました.
これは、どのような種類のソフトウェアを作成するかに大きく依存すると思います。たとえば、私は小さな会社の社内システムを開発しているので、次のように選択します。
[company].[project].[sub].xyz(.abc)
subは通常、、clientおよびcommonのいずれかですserver。もし私が(商用の)ソフトウェア会社で働いていたらproject、プロジェクトの開始時にアプリが呼ばれていたものと、プロジェクトが終了したときにアプリが呼ばれていたものは、2 つの完全に別のものである可能性が高いため、このビットを使用するのはもっと気が進まないでしょう。 ! ここでは:
oak.lang.Object
これは非常に便利で、他の人 (XML スキーマなど) によってコピーされています。
これは「大規模な」(WWW を考えると) 場合に役立ちますが、部門をまたがる場合 (つまり、小規模な場合) にはおそらくより有用です。小規模なプロジェクトでは肥大化しているように見えるかもしれませんが、保険のように機能します。後で必要になったときにそこにあるのです。
はい、リバース ドメイン命名規則を使用して JavaScript で名前空間を作成するスキームを考案しました。これにより、特定のアセットとその役割をより簡単に見つけることができ、名前の衝突を防ぐのに役立ちます。
はい、パッケージの先頭にリバース ドメインを使用し、その後にその他の管理情報 (プロジェクト、部門など) を使用します。ドメインを使用すると、ベンダー/企業/FOSS プロジェクト間の衝突の可能性が最小限に抑えられます。ドメインのおかげで、私の「データ」パッケージが他社のデータ パッケージと衝突することはありません。
また、外部での使用を意図していない内部作業またはクラス (おそらく文書化されていないサポート ライブラリなど) の tld を削除するという規則も使用しました。通常、これにより、コード ブロックに異なるルールやポリシーが適用される可能性があることが、他の開発者に明らかになります。
リバース ドメインを使用すると、ルールや確立されたパターンに従わない任意の名前空間よりも混乱が少なくなります。
私はすべてのプロジェクトでこれを行います。名前空間用の .NET アプリケーションにも適用しました。