1

単一のモジュール内で作業する場合の依存関係の反転は理解していますが、モジュール間の依存関係がある場合にも適用したいと考えています。次の図では、既存のアプリケーションがあり、参照データ サービスのいくつかの新しい要件を実装する必要があります。新しい jar を作成しようと思いました (将来的にはスタンドアロン サービスになる可能性があります)。最初の図は、私が過去にそのようなことに取り組んできた通常の方法を示しています。referencedataservices jar には、アプリがそれを呼び出すために使用するインターフェイスがあります。

2 番目の図は、DIP を使用しようとした私の試みを示しています。現在、アプリはその抽象化を所有しているため、参照データ サービスが変更されたからといって変更されることはありません。ただし、循環依存関係が作成されるため、これは間違った設計のようです。MyApp は referencedataservices jar に依存し、referencedataservices jar は MyApp に依存します。

したがって、3 番目の図は、追加の抽象化レイヤーを作成することによって、より通常の依存関係に戻ります。私は正しいですか？それとも、これは本当に DIP が意図したものではないのでしょうか? 他のアプローチやアドバイスについて聞くことに興味があります。

、依存関係反転図

4

2 に答える 2

1

2 番目の例は、実装をその抽象化から分離することによって正しい軌道に乗っています。モジュール性を実現するには、具体的なクラスをその抽象インターフェイスと同じパッケージ (モジュール) に含めないでください。

2 番目の例の欠点は、クライアントが抽象化を所有し、サービスが実装を所有していることです。これら 2 つの役割は逆にする必要があります。サービスはインターフェイスを所有します。クライアント独自の実装。このようにして、サービスはクライアントが実装するコントラクト (API) を提示します。このサービスは、その API に準拠するすべてのクライアントとの対話を保証します。依存関係の逆転に関しては、クライアントは依存関係をサービスに注入します。

Kirk K. は、Java のモジュール性に関する権威のような存在です。彼はブログを持っていて、それが最終的にこのテーマに関する本になりました。彼のブログは現在行方不明のようですが、Wayback Machine で見つけることができました。Applied Modularityというタイトルの 4 部構成のシリーズに特に興味があると思います。DIP の他のアプローチまたは代替手段については、Fun With Modulesをご覧ください。そのうちの 3 つが取り上げられています。

于 2015-09-07T13:40:14.407 に答える
0

あなたが提示した2番目のアプローチでは、RefDataSvc抽象化を別のパッケージに移動すると、サイクルが壊れ、パッケージは抽象化されたパッケージreferencedataservicesのみを使用しますRefDataSvc。

パッケージ内のコンポジション ルート以外のコードMyAppも に依存する必要がありますRefDataSvc。次に、アプリケーションのコンポジション ルートで、アプリに必要なすべての依存関係を作成する必要があります。

于 2015-09-07T07:20:16.260 に答える