3つのオブジェクトを疎結合およびカプセル化するには、どのデザインパターンを使用すればよいですか？
私が抱えている問題を解決するために、さまざまなデザインパターンを調べてみました。 3つのオブジェクトを疎結合してカプセル化します。
オブジェクト1：Spring Data Repository：
永続層を公開するためのオブジェクト。
オブジェクト2：Restテンプレートサービスオブジェクト：
REST APIでアクションを実行し、さまざまなエンドポイントのさまざまなメソッドを含むオブジェクト。JSONは、この応答に合わせて特別に調整されたOrderクラスにデシリアライズされます。
オブジェクト3：Restテンプレートサービスオブジェクト：
異なるREST APIでアクションを実行するオブジェクト2とは異なるオブジェクト。JSONは、この応答に特化したOrderクラスにシリアル化されます。
私が抱えている問題は、3つのオブジェクトを疎結合にして、新しい残りのテンプレートサービスオブジェクトを追加したり、指定したリポジトリを変更したりしやすくすることです。このサービスオブジェクトは使用できませんが、サービスオブジェクト3、4、5は使用できます。現在、サービスオブジェクト1とサービスオブジェクト2の仲介役として機能するオブジェクトがあります。中間オブジェクトには、リポジトリオブジェクトのインスタンス変数が含まれています。現在、中間者オブジェクトは3つのオブジェクトすべてに密結合されています。これら3つのオブジェクトを疎結合にするための最良の方法は何ですか？メディエーターパターンを確認しましたが、それが最善のアプローチかどうかはわかりません。私はデザインパターンを練習していて、この問題に遭遇しました。
問題ドメインについてもう少し。ローカルに保存されるデータは、生成された注文です。サービスオブジェクトはREST新しい注文の通知が必要なエンドポイントです。これはエンドポイントの1つにすぎませんが、他の注文は注文Xのラインアイテムをキャンセルします。したがって、新しい注文が作成されると、データベースが新しい注文で更新されます。1日の特定の時間に、サービスオブジェクトを使用してさまざまなRESTエンドポイントで新しい注文が作成されます。
追加の情報が必要な場合は、お知らせいただければ幸いです。私はデザインパターンを練習していて、この問題に出くわしたので、決して専門家ではありません。
兄弟の「戦略パターン」は少し近いと思います。 Mediatorは、疎結合されたオブジェクトがMediatorを介して互いに通信できるようにするためのものです。戦略とは、要求を満たすために適切な疎結合オブジェクトを選択することです。
別のパターンのプレイブックには、「Service Locator」パターンがあり、これも適合しているようです。
実際には、通常、サービスインターフェースと、そのインターフェースに準拠する具体的なサービスを作成します。 DIコンテナをサービスロケーターとして活用できます。
一見すると、それは メディエーターパターン を使用するための良いケースのようです。
このパターンでは、メディエーターは、同僚オブジェクト（リポジトリとさまざまな残りのテンプレートである可能性があります）間の相互作用を管理します。大きな利点の1つは、これにより、複雑な多対多の対話が2対1対多の対話に置き換えられると同時に、同僚が切り離されることです。