私は、さまざまな要素が同じ種類の「コンテキスト」を受け入れ/生成することに基づいた、ある種のフィルタリングシステムを作成しています。
たとえば、次のようにプロセスをモデル化できます。
{generate_numbers(1..100)} --> {is_prime} --> {output}
コンテキストは単純な「HashMap」にすることができます。generate_numbers
'x' が何らかの数値に設定されたコンテキストを作成is_prime
し、このコンテキストを使用して 'x' を探し、それに応じて 'prime'=true/false を設定します。
長所:
- 柔軟性 (さらに簡単に拡張可能 (HashMap))
短所:
- 型のない値はいたるところにキャストされます
すべてを「コンテキスト」のフィールドとして宣言することも実行可能なアプローチですが、この方法では簡単に拡張できることが犠牲になります(私はそれで暮らすことができます)
しかし...状況はもう少し複雑です。これは、これらの変換要素がアプリケーションのパッケージ全体に散らばっているためです。
{generate_numbers(1..100)} --> {is_prime} --> {calc(f_1)} --> {output}
{--------------- pkg_A ------------------} | {--------- pkg_B -------}
したがって、pkg_A が何らかの作業を行う部分があり、次に pkg_B 部分がコンテキストを処理する場所があります --> そのため、2 つの方法を混在させたいと考えています。
私は次のアイデアを思いつきました:
オプション1
- コンテキスト E を含む基本的な HashMap に名前を付けたとします。
- ゲッター/セッターが利用できるフィールドにいくつかのエントリが表示される E のサブクラスを作成します
- すべての処理関数で、着信引数を必要なクラス型にキャストします
プロ:
- 実装が比較的簡単
短所:
- HashMap コンテンツとフィールドを同期する必要があります
- 複数の方法で値にアクセスすると、混乱が生じる可能性があります
オプション 2
- キャストを行ういくつかの「ツール」クラスを作成します
プロ:
- すべての関数でサブクラスのランタイム キャストがない
短所:
- アクセスは常に HashMap アクセスに変換されます
- フィールドが読み取られるたびにキャストがあります
オプション 3
私は完全に間違っています。別の方法で問題に対処する必要があります
アップデート:
「コンテキストクラスを昇格させる方法は?」現在のワークフローでは、これらの情報は制御ロジックでぼやけているため、アプリケーションが作業しているすべての厄介なものを運ぶ比較的便利なコンテキストをどのように作成できるかを意味します