2

実際の大規模プロジェクトでのパッキング方法を理解したい。

パッケージ com.abc.xyz があるとします。このために、実際には com/abc/xyz のようなパスがあります。

次のような異なるディレクトリ構造に複数の同じパッケージ名を含めることは可能ですか?

ディレクトリ パス 1: /home/user1/project/module1/src/java/com/abc/xyz

ディレクトリ パス 2:

/home/user1/project/module2/src/java/com/abc/xyz

最後に、プロジェクト全体の jar を作成する場合、com ディレクトリに対して jar を作成しますか?

一部のアプリケーションが import com.abc.xyz を使用する場合、参照しているディレクトリ パスのパッケージをどのように認識しますか?

最後に、パッケージングに関するガイドライン、プロジェクトをモジュールに分割する方法、パッケージ名などを提供する優れた本/リソースはありますか?

もう1つ、プロジェクトには上記の場合のような共通のパッケージベース名がありますか: com.abc.xyz (例: org.apache.hadoop )。

ありがとう、ヴィピン

4

4 に答える 4

4

クラスローダに関する限り、異なるソース ディレクトリに作成されたパッケージは同じパッケージです。また、クラス ファイルが同じ jar にあるか、異なる jar にあるかは問題ではありません。JVM は、ソース コードがどこから来たかに基づいて区別しません。(もちろん、異なるクラスローダーによってロードされた 2 つの jar がある場合、それらは異なる方法で処理されます。)

同じパッケージで異なるソース ツリーを頻繁に使用するケースの 1 つは、別のディレクトリにテストがある場合です (コードが src/main/java の下にあり、テストが src/test/java にある通常の Maven 規則を使用)。彼らが実行するコードと同じパッケージで。これらのテストは、コードと同じパッケージにあるため、テスト対象のコードの保護された部分とパッケージ プライベートな部分を実行できます。

jar 内のディレクトリのパスは、パッケージのルートから開始する必要があります。(最上位のディレクトリは / で、次に com や org などと呼ばれるディレクトリにする必要があります。) パッケージはツリーのような構造を形成し、コードをファイルシステムに配置すると、最終的にパッケージの階層ができますが、言語はそれ自体は「サブパッケージ」の概念を認識しません (ただし、java で始まるパッケージは特別であり、クラスローダーによって特別に扱われます)。

コードをパッケージに編成する方法は、人によって異なります。レイヤーごとにコードを整理するのが好きな人もいれば (すべてのコントローラーを 1 つのパッケージに入れ、すべてのサービスを別のパッケージに入れ、すべての daos をさらに別のパッケージに入れる)、コードを機能別に整理するのが好きな人もいます。

パッケージごとのレイヤーは、コードを編成する従来の方法であり、Java コミュニティーでは好んで使用されているようです。この結果の 1 つは、コードが機能をパッケージ構造に直角な垂直スライスとして実装する場合 (新しいコントローラー エンドポイント、おそらく新しいサービス メソッドなどが必要になる可能性があるため)、密接に関連するコードのビット同じ機能が異なるディレクトリに散らばってしまいます。Java Practices の Web サイトでは、package-by-feature の興味深い事例が紹介されています。

機能別パッケージ機能別パッケージでは、パッケージを使用して機能セットを反映します。単一の機能に関連するすべてのアイテム (およびその機能のみ) を単一のディレクトリ/パッケージに配置しようとします。これにより、凝集度が高く、モジュール性が高く、パッケージ間の結合が最小限に抑えられたパッケージが得られます。密接に連携するアイテムは、互いに隣り合わせに配置されます。それらはアプリケーション全体に広がっているわけではありません。場合によっては、機能の削除が 1 つの操作 (ディレクトリの削除) に短縮されることにも注意してください。(削除操作は、最大のモジュール性をテストするのに適していると考えることができます。アイテムは、単一の操作で削除できる場合にのみ、最大のモジュール性を持ちます。)

これは、機能またはレイヤーごとにパッケージについて尋ねるSO の質問です。

于 2014-04-04T15:26:02.590 に答える