java observerパターンでは、Subjectにはオブザーバ・レジスタがSubjectに登録されたオブザーバのリストがあります。java：observer pattern理論上の問題
1000人のオブザーバーがSubjectに登録しているとします。サブジェクトはサブジェクトクラスのリストを持っています。
数日後、オブザーバーはもはや被験者からの通知には関心がありませんが、オブザーバーは登録を忘れる（または彼は怠惰です）ことを忘れてしまいます。
ここでは、SubjectにはList内の不要なオブザーバのオブジェクトが含まれており、メモリを無駄にしています。
メモリが本当に重要でメモリを浪費したくない場合の解決策は何ですか？
解決策は弱い参照ですか？
登録を行っている間は、登録者は10日後に再登録する必要があります。
あなたがしようとしているのは、ユースケース（ニュースレターの登録/登録解除など）とデザインパターン（オブザーバー）を比較することです。ユースケースはビジネスニーズに基づいています。ユーザーを失いたくない場合は、登録済みのリストから削除することは望ましくありません。 一方、お客様のビジネスニーズに応じて、ユーザーを悩ませたり、非アクティブなユーザー（これらのニュースレターからのクリック率を追跡している）に煩わされたくない場合は、しばらくしてから削除することができます。
ユースケースはデザインパターンと同様に実装できますが、アプリケーションエリアはまったく異なります（通常、プレゼンテーションレイヤではObserverが使用されます）。実際のデザインパターンとはほとんど関係がありません。
ユースケースの変更やバリエーションを反映させるために、インターフェイス契約の一部である場合には、リストの削除を実装することもできます（ただし、通知で行うこともできます）。結局、のパターン。
サブスクライバーがあなたの支配下にある場合、サブスクライバー側から問題を解決する必要があるため、オブザーバーからサブスクリプションを削除します。
一方、サブスクリプションが公開されている場合は、登録を解除する必要があるシステムを無視する可能性があります。まだ登録されていないシステムと、まだ登録されていないシステムを区別することはできません。
サービスが一定の時間間隔で支払われると、タイムアウトのあるサブスクリプションが有効になります。
_ "オブザーバーは忘れています（または彼は怠け者です）。登録を解除する" _ - これはバグと呼ばれます。 –
実際のシナリオでは、これは通常発生します。私たちはyoutubeチャンネルに登録し、通知を受け取ります。 YouTubeは私に通知を提供しますが、私は興味がありません。私はメモリの問題はありません、YouTubeは私に通知を送信し続けます。しかし、あなたがYouTube側で見ると、それは記憶の浪費です。私はテレコムのシナリオでこのような状況に直面しています。 – VJS
@VJSなので、もし興味がないなら、また登録解除オプションもあります。コンピュータは、ユーザーの心ではなく、そのメモリを読み取ることができます。 :)） –