問題タブ [immutability]

私が非常に不変な型を持っている場合 (すべてのメンバーは読み取り専用であり、それらが参照型のメンバーである場合、それらは非常に不変なオブジェクトも参照します)。

次のように、型に遅延初期化プロパティを実装したいと思います。

私が言えることから：

...スレッドセーフです。両方のスレッドが同時に初期化するために競合することについてはあまり心配していません。これはめったにないためです。論理的な観点からは両方の結果が同じであり、ロックがない場合はロックを使用したくないからです。に。

これは機能しますか？長所と短所は何ですか？

編集： 回答ありがとうございます。おそらくロックを使用して先に進みます。しかし、コンパイラが temp 変数が不要であることを認識し、m_PropName に直接代入する可能性を誰も持ち出さなかったことに驚いています。その場合、読み取りスレッドは、構築が完了していないオブジェクトを読み取る可能性があります。コンパイラはそのような状況を防ぎますか?

(回答は、ランタイムがこれを許可しないことを示しているようです。)

編集:そこで、Joe Duffy によるこの記事に 触発された Interlocked CompareExchange メソッドを使用することにしました。

基本的：

これにより、このオブジェクト インスタンスでこのメソッドを呼び出すすべてのスレッドが同じオブジェクトへの参照を取得するようになるため、== 演算子が機能します。無駄な作業が発生する可能性がありますが、これは問題ありません。楽観的なアルゴリズムになるだけです。

以下のコメントにあるように、これは動作する .NET 2.0 メモリ モデルに依存します。それ以外の場合、m_PropName は volatile と宣言する必要があります。

プログラムの別の部分で使用するために、Java の PriorityQueue クラスを clojure でラップしたいと考えています。私が理解しようとしているのは、これを巧妙な方法で実行し、優先キューを不変にする方法があるかどうかです。これを行う良い方法はありますか、それとも PriorityQueue を変更可能なデータ構造として使用したほうがよいでしょうか?

命令型のオブジェクト指向言語では、ミュータブルまたはイミュータブルなクロージャーを持つ方が理にかなっていますか?

例えば：

クロージャーが変更可能な場合、これは次のように出力されます。

不変の場合は、次のように出力されます。

不変のクロージャーを使用しても、これを実行できることを認識しています。

では、ミュータブルまたはイミュータブルなクロージャーを用意した方がよいでしょうか、それとも両方のオプションを用意したほうがよいのでしょうか? イミュータブル クロージャは実装しやすいように思われるので、現時点では、そうしない正当な理由がない限り、それを使用すると思います。

不変リストがある場合、たとえば、要求すると常に同じオブジェクトへの参照が返されることが期待されます。

私の質問は、オブジェクトを変異させ、次にリストから取得したときにその変異を反映させることができると思いますか?

あまり知識がなかったときに書いた Python コードの一部を整理しています。主に、Python のスレッド化についての不完全な理解に起因する複雑さの一部を解消しています。アイテムのリストをスレッドセーフにする必要があり、通常のロック方法ではなく、不変リストを介して行いたいと考えています。不変オブジェクトは、スレッド化に関して非常に特別であることを私は知っています。不完全な状態変更を取り巻くすべてのスレッド セーフの問題が単純に解消されるからです。

それで、私は尋ねます: 次のコードはスレッドセーフですか?

毎回新しいリストが作成されるため、そうであると思います。別のスレッドがリストを反復している間にリストが更新された場合、反復の残りの部分では古いリストが引き続き使用されます。これは私には問題ありませんが、万人向けではないかもしれません。

また、これは良い考えですか？リストのサイズが小さく、リストがあまり変更されないいくつかの状況にのみこれを適用したいと思います (イベント リスナーが思い浮かびます)。

私はインピーダンスの不一致によって運命づけられているかもしれませんが、IRepository と不変オブジェクトで見た例を調整しようとしています。

私は、何百もの Web リクエストが製品の「ワーキング セット」で動作するカタログ作成アプリケーションに取り組んでいます。カタログ全体のサブセットが常に使用される傾向があります。

同時に、当社のデータ チームは常に製品データを更新しています (新しい画像、更新された価格、説明など)。

パフォーマンスのためには、製品を不変と考えたほうがよいように思えます。それらはリポジトリによってロードおよびキャッシュされ、多くのスレッドが同じ製品オブジェクトに同時にアクセスできます。

しかし、この考えは、私が Update/Delete メソッドで見た IRepository の例の多くで壊れているようです。

そこで私は、エンティティへの変更がコンパニオン 'editor' オブジェクトを介して行われ、変更を保持し、問題の製品を強制的にリロードして全員が使用できるようにする 'editor' モデルを想定しました。製品が変更されることはありません。外部から「編集」されて再ロードされるだけです。

これは意味がありますか？説明されているように、これはリポジトリで機能しますか?

私はこのプロジェクトに参加しており、かなりのレガシー コードを基に構築しています。ワイヤ経由で転送する必要がある 1 つの大きな Java Bean オブジェクトについて、特定の状況があります。したがって、私の最初の考えは、トリックを実行するために不変かつシリアライズ可能にすることでした。この時点で、いくつかの難しい選択に直面しています:-

1. 理想的には、このクラスの不変でシリアル化可能なバージョンを自動的に生成する何らかの方法が必要です。このクラスを何らかの方法でリファクタリングまたは変更する範囲がありません。別の名前でクラスをコピーして貼り付ける必要があるのは本当に嫌いですか?

2. 1つをあきらめたと仮定すると、つまり、実際に巨大なjavabeanクラスのコードを複製することを選択した場合でも、このクラスを不変にするために20〜25個のパラメーターを持つコンストラクターを作成する必要があるという不快な状況になります。コンストラクター注入以外にクラスを不変にするより良い方法は何ですか?

よろしくお願いいたします。