1

わかりました、私はこのようにプロジェクトを構成することに慣れています

|--com.mycompany.interfaces
|         |--IFoo1(public)
|         |--IFoo2(public)
|         |--IBar1(public)
|         |--IBar2(public)
|
|--com.mycompany.foos.impl
|         |--Foo1(default) implements IFoo1
|         |--Foo2(default) implements IFoo2
|
|--com.mycompany.bars.impl
|         |--Bar1(default) implements IBar1
|         |--Bar2(default) implements IBar2
|
|--com.mycompany.services
|         |-FooBarService (public)

すべてのインターフェイスを整理するための 1 つのパッケージがあり、実装は独自の関連パッケージにあります。

public クラス FooBarService は、インターフェイス IFoo1、IFoo2 などを介して、Foo1、Foo2 などのインスタンスをこのプロジェクト外の呼び出し元に返す必要があります。ただし、クラス FooBarService は具体的なクラス Foo1、Foo2 などにアクセスできません。これらはパッケージ スコープであるためです。

具体的なクラスを外部のライブラリに公開せずに、実装を意味のある複数のパッケージに保持する良い方法は何ですか? またはそれは可能ですか？.netでは、具象クラスを として指定するだけinternalで、実装されている場所や名前空間が何であれ、Javaでそのような構造を使用できるかどうか疑問に思っていますか?

4

4 に答える 4

2

まず、これらすべてのインターフェースが本当に必要ですか? フレームワークやライブラリを構築したり、複数の実装を予見したりしない限り、良い設計のように見えるため、インターフェイスを作成することはありません。最新の AOP とモッキング ライブラリと魅力のようにリファクタリングできる IDE では、何百ものインターフェイスを作成してもほとんどメリットがありません。特別な（またはすべての）セッターを隠すためだけに、すべてのJava Bean POJOのインターフェースを作成するのは特に（IMHO）ばかげています。良いデザインに見えるのは分かっていますが、KISS の方が優れています。

そうだとしましょう。 プロジェクトの依存関係でパッケージの可視性を処理する必要があります。これは、複数のプロジェクト (マルチ モジュールの maven プロジェクトなど) を作成するのが最善の方法です。

何かのようなもの

myproject
|  | myproject-api  // interfaces here, depends on pretty much nothing
|  |  | src
|  |  | pom.xml // or build.xml or whatever
|  | myproject-foo // implementations here, depends on myproject-api
|  |  | src
|  |  | pom.xml // or build.xml or whatever
|  | myproject-bar //implementations here, depends on myproject-api and maybe foo.
|  |  | src
|  |  | pom.xml // or build.xml or whatever
|  pom.xml  // or build.xml or whatever

myproject ビルドは 3 つの異なる jar を生成します (名前は異なる場合があります): myproject-api.jar、myproject-foo.jar、myproject-bar.jar

より専門的な組織を探している場合は、この人のブログを見る必要がありますが、個別のプロジェクトに分離しない限り、(C# のように) 実際に強制することはできません。

また、正規の Java SPI プラクティスと依存性注入(現在は .NET で標準化されている)にも精通している必要があります@Inject。

サービスに対して@his 静的メソッド ファクトリ パターンを実行することはお勧めしません(特に、インターフェイスのインスタンスをインスタンス化する場合)。これを行うと、せいぜいサービスロケーターパターンが発生しますが、開発者がコンストラクター (つまり、集約構築パターン) で依存オブジェクトを配線し、場合によっては邪悪なシングルトンパターンになるという、さらに悪いことが起こる可能性があります。最後に、静的メソッドは常に使用可能であり、(DI と比較して) 予測不可能な使用法とライフサイクルにつながります。

また、あなたが本当に冒険好きなら、 OSGI を見に行くことができます。

SPI と OSGI に関係なく、マルチモジュール アプローチを強くお勧めします。

于 2013-04-03T02:40:11.407 に答える