問題の説明を簡潔にしようと思います...
スレッド プールは、チェーンされたタスクを実行します。各タスクは抽象クラスから継承します。それらのほとんどは外部サービスを扱い、サービスと対話するように調整する必要があります。各タスクには、オブジェクトまたはオブジェクトのリストが含まれます。これを TaskObjects と呼びますが、String、Integer、MyClass などの場合もあります。タスクが完了すると、TaskObject と追加のデータが応答のコレクションに配置されます。オブジェクトとそれを渡します。一連のタスクが完了すると、コレクションがメイン スレッドに返されます。
メインスレッドは応答を評価し、それらの応答に基づいて実行するアクションを決定します。これらは即時のアクション (つまり、TaskObject をプルし、操作し、結果を次の利用可能なスレッドで実行するための新しいタスクに配置する) である場合もあれば、アクションをトリガーするためにそのタイプの N 個の応答を蓄積する必要がある場合もあります。 (つまり、TaskObject をプルし、場合によってはそれらを操作し、ローカル コレクションに配置します。N 個の TaskObject(s) が M 時間にわたってそのコレクションに蓄積された場合、それらの TaskObject(s) に対してアクションが実行されます)。アクションは、応答コレクション内の他のタスクに関連して応答が発生した場所に基づいている場合もあるため、応答は個別に処理できません。
私が直面している問題は、さまざまな TaskObjects を処理することです。それらは共有クラスから継承しません (もちろん Object を除く)。ポリモーフィズムは役に立ちません。メインスレッドでの評価の性質は、物事を複雑にします。オプションを検討していますが、どれも非常に「良い」とは思えません...
- 物事を処理したり、ビジターを使用したりするためのタスク/応答への委譲。各タスクは、自分自身の行動や次のタスクが何であるかを認識していないため、これは困難です。結果を処理するために何らかの「集中型」サービスに結び付ける必要があり、スレッド セーフを考慮に入れる必要があり、すべての応答をコレクションにまとめると複雑になります。実行可能ですが、ある混乱を別の混乱と交換することもできます.
- ジェネリック。一部の階層を平坦化するのに役立つ可能性はありますが、T の型やその処理方法がわからないため、TaskObjects を処理するメイン スレッドの問題は解決しません。こんにちは型チェック条件。ブリーチ。
- 応答オブジェクトのタイプチェックを完全にやめてください。
- すべてのタイプのフィールドを持つ応答内の TaskObject(s) のラッパーを作成し、抽象クラスに配置します。これで、何を扱っているかを調べるために、すべてを nullcheck することができます。あまり良くありません。
この種のことを処理する「良い」方法があるかどうかはわかりません。一般的な問題は、Java に限ったことではありませんが、この特定の苦境は、Java 特有のものかもしれません。おそらく、これをきれいに処理する方法はなく、少しリファクタリングして、最も悪いソリューションを実装する必要があるだけです。
繰り返しになりますが、私は物事を複雑にしすぎている可能性があり、はるかに良い選択肢は私の鼻の下に座っていることです...