変更可能性と性能の間のツリー構造のトレードオフを処理する方法

Question

ツリー構造ライブラリの実装に関連しているが、これは重要な問題の1つです。

私は2つのコアコンストラクタがあるとします：TreeとNodeです。
Treeオブジェクトには、ツリーを管理し、Nodeオブジェクトへの参照を取得するメソッドがあります。

私が回避できない問題は、Nodeオブジェクト（およびその子）が不変でなければならないということです。それは、現在のツリーに影響を与えると内部の仕組みを台無しにします

var childNodes = Tree.findNode(5).children; 
var node = children[0]; 
node = "overwrite with something"; 

または

var parentNode = Tree.findNode(5).parent; 
parentNode.children = { text: "Doesn't realize this will change the original node's children" }; 

：私たちが望んでいないことは、ライブラリのユーザが、内部構造を変異させることができるということです。

また、不変のオブジェクト/配列で作業すると仮定すると、それは連続コピーを意味します。
ツリー構造上の10のランダムノードを1つのノードに（下に）移動したいとします。つまり、配列を変更するためにコピーを作成し、配列全体を再割り当てすることを意味します。 （配列の長さはわからない！）。これは、変更可能なデータ構造ではコストがかからないために莫大な過度の余裕があるようです。それは私の脊柱の中でも、コード志向の面でもっと面倒だと感じています。

私は多くの回避策を試しましたが、最終的に同じジレンマに終わります。
どうすれば解決できますか？

編集：私のユースケースでは順序が重要であるため、ノードの子として配列を使用することをほとんど忘れていました。

Answer 1

私は不変のノードオブジェクトを使うことに決めました。これは、libのユーザが誤って内部の動作を台無しにするのを許さないようにするためです。

あまりにも多くのコピーを作成したために苦しんでいたパフォーマンスに懸念がありました。私が学んだように、不変オブジェクトを処理するための効率的な方法があります。これはImmutablejsが提供するものです。
いくつかのプレゼンテーションを見て、ドキュメントを読んだ後、私は、必要な柔軟性を提供する広範なAPIにうれしく驚きました。

戦略は、不変オブジェクトまたはネイティブなJavascriptオブジェクトを返すかのどちらかをユーザーに選択させることです（React、Immutableで作業する場合は非常に一般的な選択肢です）。しかし、内部的には、ライブラリは不変オブジェクトを使用します。

@SebstienDanielこの提案をお寄せいただきありがとうございます。