深さが 20 代のツリー オブジェクトのセットがあります。このツリーの各ノードは、そのツリーのルートにアクセスする必要があります。
いくつかの解決策:
(任意のバリエーションで) グローバルを使用しないが、メモリまたはサイクルの両方でそれぞれ #1 または #2 よりも効率的な設計を誰かが提供できますか?
編集:私はツリーのセットを持っているので、ツリーを区別するのが難しいため、単純に静的に格納することはできません。（ありがとうマカルト）
ルートを必要とするノード内の関数にパラメータとして渡します。
編集：オプションは実際には次のとおりです。
これがすべての可能性だと思います。選択肢 5 はありません。
なぜグローバルを廃止する必要があるのでしょうか? グローバルが悪いという汚名を着ていることは理解していますが、すべての要素を含むグローバルデータ構造を持つことが最速の解決策である場合があります。
コードの明快さとパフォーマンスに関する将来の問題の軽減というトレードオフがあります。それが「まだ最適化しない」という意味です。最適化段階にあるため、パフォーマンスを優先して、読みやすさと優れたプログラミング手法を切り取る必要がある場合があります。つまり、ビットごとのハックは判読できませんが、高速です。
ツリー オブジェクトがいくつあるかわかりませんが、個人的にはオプション 1 を使用します。数千以上の木を扱っていない限り、ポインターは実際には数個の文字列よりもはるかに多くなりません。メモリが非常に重要な問題である場合は、両方の方法を試して (実装はかなり簡単に思えます)、プロファイラーで実行してください。または、優れたProcess Explorerを使用してください。
編集: 私が取り組んでいるアプリの 1 つには、約 55K のノードを含むノード ツリーがあります。ツリー構造を構築しますが、O(1) ルックアップ用の配列も維持します。再帰的な FindNodeByID メソッドを使用したときに取得していた O(m*n) よりもはるかに優れています。
通常、ルートをパラメータとして渡すのが最適です。ツリーをナビゲートするためにある種のイテレータを使用している場合、別の方法として、その中にルートへの参照を格納します。
ポイント 1 は、時期尚早のメモリ最適化です。#2 は時期尚早のパフォーマンス最適化です。メモリまたは CPU のボトルネックが問題を引き起こしているかどうかを判断するために、アプリのプロファイリングを行いましたか? そうでない場合、ユーザーの役に立たない「最適化」のために、保守しやすい設計を犠牲にする必要はありません。
#2 を使用することを強くお勧めします。代わりに計算できるものを保存するときはいつでも、あなたがしているのはキャッシュです。キャッシングが良いアイデアである場合も数回ありますが、これはメンテナンスの頭痛の種でもあります。(たとえば、親を変更してあるツリーから別のツリーにノードを移動し、ルート フィールドも更新するのを忘れた場合はどうなるでしょうか?) 必要がない場合はキャッシュしないでください。
TreeView からクラスを派生させてから、シングルトンの静的プロパティを追加できます。そうすれば、クラスの単一のインスタンスを参照するグローバル フィールドを効果的に追加できますが、そのクラスに限定された名前空間であるという利点があります。
内部クラスに対する嫌悪感を無視して、Tree クラスを定義し、ノードを内部クラスとして定義することができます。各ノードは、ルートを含むツリーの状態にアクセスできます。
これは、Java がノードを親に関連付ける方法によっては、#1 と同じになる可能性があります。（よくわからないので、プロファイルする必要があります）