次のことを行うツールを開発します。
クライアントからは、5 分または 10 分ごとにサーバーにリクエストを送信します。次に、サーバーはファイルのリストを送信します。この部分を「コレクション」と呼びます。「収集」の後、「エクスポート」を行う必要があります (「収集」期間中に収集されたすべてのファイルを統合します。
私の考えでは、上記の「収集」と「エクスポート」のアクションは、「生産者」と「消費者」のようなものです。では、「オブザーバー」パターンを使用して上記のアクションを実装できますか? そうでない場合は、他のデザイン パターンを提案してください。
よろしく、カンナンDV
2 つのコンポーネントは自然に疎結合であるため、別々に設計、実装、およびテストできます。ここで既知のパターンのいずれかが本質的に必要だとは思いません。
ただし、コレクターから通知を受け取りたい場合は、実際に Observer パターンを調べることができます。
観察者。オブジェクト間の 1 対多の依存関係を定義して、1 つのオブジェクトの状態が変化すると、そのすべての依存関係が通知され、自動的に更新されるようにします。
一方、私が理解しているように、エクスポートはエクスポーターが要求したときに行われるのではなく、一定の間隔で行われるため、エクスポーターはいつでもコレクションを取得できるため、おそらくコレクターに何らかのキャッシュメカニズムが必要になるでしょう(通知システム）。
ここで難しいのは、消費者がコレクションを正常に受け取ったことを生産者が知る必要があるという事実を確認/管理することです。
ファイルを送信しても受信確認を受信しない場合、次のコレクションのためにファイルを自動的に所定の位置に残し、消費者にすべてを整理させますか?それとも、ヒューマン タスクとして管理するための UI が必要ですか? 、 または何？
サーバーは事前にコレクターに通知できません。そのため、コレクターはサーバーをポーリングしています。これは、コレクターとサーバーの間に適用可能なオブザーバー パターンがないことを意味します。
エクスポータに自律的にプロセスを開始させたい場合は、コレクターが通知を配置する BlockingQueue を与えることができます (つまり、どのファイルをエクスポートする必要があるかを示す「ジョブ」オブジェクト)。エクスポーターは次の Job を取得するために queue.take() を繰り返し呼び出します。BlockingQueue.take() は、CPU を占有することなく、要素がキューで使用可能になるまで待機することに注意してください。サンプル コードが含まれているhttp://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/BlockingQueue.htmlを参照してください。
有望ですね。ここで適切なアドバイスをするために、誰かがあなたのコンテキストとツールへの期待についてさらに情報を必要とするかもしれません. コンポーネントに適切な責任の割り当てを見つけるのはあなた次第です。
この記事は、コンポーネントの適切なスライスを見つけるのに非常に役立ちます。
オブザーバー パターンは、適切な設計でここに適用できます...現在、サーバーをポーリングしてデータを消化していますが、これは本質的にオブザーバー パターンには適していません (投稿を正しく理解していれば)。ここでの 2 つの適切なオプションは、変更/更新/追加をエクスポートする準備ができたときにサーバーが JMS キューに通知するようにすることです。その後、オブザーバー パターンを使用してメッセージを受信し、それらをダイジェストできます。または、サーバーでデータをフィード (RSS など) に公開してから、フィードをポーリングして通知を作成するサービスを用意することもできます (最後のフィード更新以降に変更があった場合)。次に、オブザーバー パターンを使用してデータをダイジェストすることができます。
サーバーが非常に頻繁にエクスポート データを生成する可能性が高い場合、これらのオプションはどちらも適していない可能性があります。 (頻繁に変更される環境ですべての変更をプッシュするのではなく)、コンポーネントを疎結合して再利用可能に保つため、従うのに適したモデルになる可能性があります。サーバーを直接ポーリングすると、おそらく再利用できないコンポーネントが作成されます（ここでは問題ないかもしれませんが、わかりません）。
それが役立つことを願っています。