古いコードをリファクタリングし、古いモンスタープロジェクトを分解し、（さまざまな理由で）小さなサブプロジェクトに分割している状況があります。あるプロジェクトには、関連する実装が別のプロジェクトにある間、ほとんどのインターフェイスが含まれることになります。パッケージ構造を設定する最良の方法がわかりません。
私は行くべきですか
org.company.interfaceproject.util.InterfaceClassおよび
org.company.implementationproject.util.ImplementationClass
また
org.company.project.util.InterfaceClassおよび
org.company.project.util.ImplementationClass
最初の実装には、ファイルが属するプロジェクトを指摘できるという利点がありますが、2番目の実装では、ファイルが異なるプロジェクトにあるという事実が混ざり合うことはありません。
ここには善悪はないと思いますが、誰か意見があれば気になります。
はい、命名規則を考え出す必要があります。通常、あいまいさを避けるために、両方の組み合わせが当社に適しています。たとえば、インターフェースがあるとします。
org.company.service.UserService
次に、Spring依存関係によって配線された、またはSpring依存関係を持っていた実装クラスに以下を使用します。
org.company.service.spring.UserServiceImpl
これには、両方の観点の長所があります。
UserService、両方のパッケージがインポートされた場合でも区別できることは明らかです。Sunには命名規則があります。パッケージの場合：
一意のパッケージ名のプレフィックスは常にすべて小文字のASCII文字で記述され、トップレベルドメイン名の1つ、現在はcom、edu、gov、mil、net、org、または英語の2文字のコードの1つである必要があります。 ISO規格3166、1981で指定されている国を特定します。
パッケージ名の後続のコンポーネントは、組織独自の内部命名規則によって異なります。このような規則では、特定のディレクトリ名コンポーネントが部門、部門、プロジェクト、マシン、またはログイン名であると指定される場合があります。
したがって、プロジェクト名を指定する2番目のオプションをお勧めします。または、次のように両方をマージします。
org.company.project.interfacepackage.util.InterfaceClass and
org.company.project.implementationpackage.util.ImplementationClass
どちらにもメリットがあります。最終的には、プロジェクトに対するあなたの意図に依存します。最終的にインターフェイスの代替実装を作成することを目的としている場合は、オプション1を使用する方が理にかなっている場合があります。これがインターフェイスの唯一の実装である場合は、オプション2の方が合理的です。
可能であれば、インターフェースクラスを別のプラグイン/パッケージに入れる必要があります。インターフェイスを使用する場合、ほとんどの場合、このインターフェイスの実装は複数あります。
私はオプション1を好む
クリントンにほとんど同意します。
最終的に、Javaに関する限り、各パッケージ名は島ですが、次のように、ビルド時に何が何とアセンブルされるかに応じて物事を分離すると便利です。
com.foo.client。* com.foo.server。* com.foo.common。*
ほとんどの場合、これによりAntファイルセットがシンプルになります。これは、ソースファイルのレイアウトがまったく異なる場合でも、ビルド方法などによって適用されることに注意してください。私が言う唯一のことは、複数のソースディレクトリで同じパッケージを取得しないように注意することです！それは醜いことがあり、偶然に行うのは簡単です。
したがって、そのような考え方で個別の高レベルパッケージを作成する必要がない限り、実装パッケージをインターフェイスパッケージ内に配置し、implパッケージに特殊化の方法を示す名前を付け、実装に名前を付けるスタイルが好きFooImplです。複数の実装をインポートする必要はほとんどありませんが、インターフェイスとimplの両方をインポートしたい場合があります。その場合は、同じような名前が付いていると便利です。