問題タブ [immutability]

皆様、

私は最近、いくつかの F# に手を出していて、いくつかの C# コードから移植した次の文字列ビルダーを思いつきました。属性で定義された正規表現を渡す場合、オブジェクトを文字列に変換します。目の前のタスクにはおそらくやり過ぎですが、学習目的のためです。

現在、BuildString メンバーは変更可能な文字列変数 updatedTemplate を使用しています。私は、可変オブジェクトなしでこれを行う方法を見つけ出すために頭を悩ませてきましたが、役に立ちませんでした。それが私の質問につながります。

変更可能なオブジェクトなしで BuildString メンバー関数を実装することは可能ですか?

乾杯、

マイケル

次のような不変型がある場合:

Origin のような内部メンバー:

使用する必要があります:

?

型は変えられないのに、本質的に同じものが多いのはなぜだろう？0 を変更することはありませんよね？

不変型で同じことを達成するにはどうすればよいですか?

不変性がどのように定義されているのだろうか？値がパブリックとして公開されていないため、変更できない場合は、それで十分ですか?

型の顧客ではなく、型内で値を変更できますか?

それとも、コンストラクター内でのみ設定できますか? もしそうなら、二重初期化の場合 (this構造体でキーワードを使用するなど) は、不変型に対してまだ問題ありませんか?

型が 100% 不変であることをどのように保証できますか?

何らかの理由で、フィールドにはオーバーヘッドが関連付けられていると常に想定してきました。これは、フィールドが初期化されているreadonlyかどうかを追跡する CLR と考えられていました。readonlyここでのオーバーヘッドは、状態を追跡するための余分なメモリ使用量と、値を割り当てるときのチェックです。

おそらく、フィールドがコンストラクター内またはフィールド宣言自体内でのみ初期化できることを知らなかったためreadonly、実行時チェックなしでは、さまざまな方法で複数回割り当てられていないことを保証できないため、これを想定しましたメソッド。しかし、今ではこれを知っています。C# コンパイラで簡単に静的にチェックできますよね? そうですか。

もう1つの理由は、の使用がパフォーマンスに「わずかな」影響を与えることを読んだことがありますreadonlyが、彼らはこの主張に関与したことがなく、この件に関する情報を見つけることができないため、私の質問です. 実行時チェック以外にパフォーマンスにどのような影響があるかはわかりません。

3 番目の理由は、それreadonlyがコンパイルされた IL に として保存されていることを確認したinitonlyことです。したがって、この情報が IL に含まれる理由はreadonly、フィールドが外部に割り当てられないという C# コンパイラによる保証にすぎない場合はどうなるでしょうか。コンストラクタまたは宣言？

一方、readonly intCLR が例外をスローすることなく、スルー リフレクションの値を設定できることがわかりました。これreadonlyは、ランタイム チェックの場合は不可能です。

だから私の推測は次のとおりです。「読み取り専用」はコンパイル時の機能にすぎません。誰でもこれを確認/拒否できますか? もしそうなら、この情報が IL に含まれる理由は何ですか?

私は自分のアプリで基本的な型のほとんどを不変にしています。しかし、コレクションも不変である必要がありますか? 私には、何かが欠けていない限り、これは大きなオーバーヘッドのように思えます。

Point3 の値などを保持するためのコレクションについて話しているので、さまざまなタイミングで追加することができます。コレクションに 1M の値があり、そのうちの 1 つを削除する必要がある場合、同じコレクションをもう一度作成する必要があります。

ハッシュ コードに関する不変型に関する考慮事項はありますか?

コンストラクターで一度生成する必要がありますか?

ハッシュコードが固定されていることをどのように明確にしますか? するべきか？その場合、GetHashCode メソッドではなく、HashCode というプロパティを使用した方がよいでしょうか。それに何か欠点はありますか？（両方を考慮すると機能しますが、プロパティが推奨されます）。

不変型にコピー メソッドを実装し、新しいインスタンスを返すことは理にかなっていますか? それとも、現在のインスタンスにする必要がありますか?

どうせタイプは変わらないと思っていたのになんでコピーするの？誰も5番をコピーしないようにね。

内部にListを格納するクラスを Java で実装しました。クラスを不変にしたい。ただし、クラスのコンテキストでは意味をなさない内部データに対して操作を実行する必要があります。したがって、一連のアルゴリズムを定義する別のクラスがあります。簡単な例を次に示します。

ラッパー.java

アルゴリズム.java

さて、私の質問は、私のクラスが不変であることを意図しているにもかかわらず、誰かが私の内部データを変更するのを防ぐ信頼できる方法はありますか? 読み取り専用のdata()メソッドを提供しましたが、誰かがclear()やremove( )などのメソッドを介してデータを変更するのを止めるものは何もありません。ここで、イテレーターを介してのみデータへのアクセスを提供できることに気付きました。ただし、 Collectionを渡すのが一般的だと言われました。第 2 に、データに対して複数回のパスを必要とするアルゴリズムがある場合、複数の反復子を提供する必要があり、これは滑りやすい斜面のように思えます。

さて、私の懸念を解決する簡単な解決策があることを願っています。私は Java に戻ったばかりで、C++でconstを扱う前にこれらのことを考えたことはありませんでした。前もって感謝します！

おー！もう一つ、ふと思ったことがあります。内部Listのコピーを実際に返すことはできません。通常、リストには数十万の要素が含まれます。

foreach ループで現在反復しているコレクションからアイテムを削除することを許可する必要がありますか?

もしそうなら、正しい行動は何ですか？