問題タブ [immutability]

私は現在、空き時間に Scala で関数型プログラミングを学んでおり、未熟な初心者の質問があります。

Haar ウェーブレット変換の計算などを行う場合、つまり、オブジェクトによって表されるデータ自体が変更されない場合に、不変オブジェクトを持つことの優雅さを見ることができます。

しかし、不変性を示すときの例として、誰かが小さなゲームを持っているブログを見ました。クリーチャー オブジェクトがダメージを受けた場合、その状態は変化しませんでした。新しいヒットポイントと新しい「X へのアグロ」フラグを持つ新しいクリーチャー オブジェクトを返しました。しかし、MMORPG のようなものを設計する場合、World of Warcraft は言います。戦場にいる 100 人のプレイヤー...おそらく数千の攻撃とバフ/デバフ スペル効果がさまざまな方法でそれらに影響を与えます。完全に不変のオブジェクトを使用してシステムを設計することはまだ可能ですか? 私には、「ティック」ごとに新しいインスタンスの巨大な群れがあるように思えます。オブジェクトの現在有効なインスタンスを取得するには、すべてのクライアントが何らかの中心的な「ゲームワールド」オブジェクトを常に通過する必要がありますか?

関数型プログラミングはこれに対応していますか、それとも「最高の仕事のための最高のツール、おそらくここでは不変ではない」のケースですか?

私のコードでは、オブジェクトが不変である場合にのみ安全な方法で、さまざまなスレッドによってアクセスされるオブジェクトのコレクションを作成しています。コレクションに新しいオブジェクトを挿入しようとしたときに、それが不変かどうかをテストしたいと思います (そうでない場合は、例外をスローします)。

私にできることの 1 つは、いくつかのよく知られた不変型を確認することです。

これで実際には 90% の方法が得られますが、ユーザーが独自の単純な不変型を作成したい場合があります。

クラスが不変であるかどうかを確実に検出できる方法 (おそらくリフレクションを使用) はありますか? 偽陽性 (そうでないときに不変であると考える) は受け入れられませんが、偽陰性 (そうでないときに可変であると考える) は受け入れられます。

編集して追加:洞察に満ちた役立つ回答をありがとう。一部の回答が指摘しているように、私はセキュリティ目標を定義することを怠っていました。ここでの脅威は無知な開発者です。これは、スレッド化についてほとんど知らず、ドキュメントを読まない多数の人々によって使用されるフレームワーク コードの一部です。悪意のある開発者から防御する必要はありません。文字列を変更したり、他の悪ふざけを実行したりするのに十分賢い人は、この場合は安全ではないことを知るのに十分賢いでしょう。コードベースの静的分析は、自動化されている限りオプションですが、すべてのレビューにスレッドに精通したレビュー担当者がいるという保証はないため、コード レビューを当てにすることはできません。

System.Arrayどういうわけか aを不変としてマークすることは可能ですか? public-get/private-set の後ろに置くと、再割り当てと再割り当てが必要になるため、それらを追加することはできませんが、消費者は必要な添え字を設定できます。

私はreadonlyキーワードがトリックを行うかもしれないと思ったが、そのような運はなかった.

可変オブジェクトと不変オブジェクトに頭を悩ませようとしています。可変オブジェクトを使用すると、多くの悪いプレスが発生します（たとえば、メソッドから文字列の配列を返す）が、これによる悪影響を理解するのに苦労しています。可変オブジェクトの使用に関するベストプラクティスは何ですか？可能な限りそれらを避けるべきですか？

私はいくつかのプロジェクトの過程で、不変 (読み取り専用) オブジェクトと不変オブジェクト グラフを作成するためのパターンを開発しました。不変オブジェクトには、100% スレッドセーフであるという利点があるため、スレッド間で再利用できます。私の仕事では、このパターンを Web アプリケーションで、構成設定や、メモリにロードしてキャッシュするその他のオブジェクトによく使用します。キャッシュされたオブジェクトは、予期せず変更されないことを保証するために、常に不変である必要があります。

もちろん、次の例のように、不変オブジェクトを簡単に設計できます。

これは単純なクラスでは問題ありませんが、より複雑なクラスでは、コンストラクターを介してすべての値を渡すという概念は好きではありません。プロパティにセッターを設定することはより望ましく、新しいオブジェクトを作成するコードは読みやすくなります。

では、setter を使用して不変オブジェクトを作成するにはどうすればよいでしょうか。

さて、私のパターンでは、オブジェクトは最初から完全に変更可能であり、1 回のメソッド呼び出しでフリーズするまで続きます。オブジェクトが凍結されると、永久に不変のままになります。再び可変オブジェクトに変えることはできません。オブジェクトの変更可能なバージョンが必要な場合は、単純に複製します。

さて、いくつかのコードに進みます。次のコード スニペットでは、パターンを最も単純な形式に煮詰めようとしています。IElement は、すべての不変オブジェクトが最終的に実装する必要がある基本インターフェイスです。

Element クラスは、IElement インターフェイスのデフォルトの実装です。

上記の SampleElement クラスをリファクタリングして、不変オブジェクト パターンを実装しましょう。

MakeReadOnly() メソッドを呼び出してオブジェクトが不変としてマークされていない限り、Id プロパティと Name プロパティを変更できるようになりました。不変になると、setter を呼び出すと ImmutableElementException が発生します。

最後の注意: 完全なパターンは、ここに示すコード スニペットよりも複雑です。また、不変オブジェクトのコレクションと、不変オブジェクト グラフの完全なオブジェクト グラフのサポートも含まれています。完全なパターンでは、最も外側のオブジェクトで MakeReadOnly() メソッドを呼び出すことにより、オブジェクト グラフ全体を不変にすることができます。このパターンを使用してより大きなオブジェクト モデルの作成を開始すると、オブジェクトがリークするリスクが高まります。リーキー オブジェクトとは、オブジェクトに変更を加える前に FailIfImmutable() メソッドの呼び出しに失敗したオブジェクトです。リークをテストするために、単体テストで使用する一般的なリーク検出クラスも開発しました。リフレクションを使用して、すべてのプロパティとメソッドが ImmutableElementException を不変状態でスローするかどうかをテストします。つまり、TDD がここで使用されます。

私はこのパターンがとても好きになり、大きな利点を見つけました。ですから、私が知りたいのは、同様のパターンを使用している方がいるかどうかです。はいの場合、それを文書化した優れたリソースを知っていますか? 私は本質的に、潜在的な改善と、このトピックに関する既存の標準を探しています。

これは、これまでに尋ねられた中で最もばかげた質問かもしれませんが、Java の初心者にとってはかなり混乱していると思います。

1. immutableの意味を誰かが明確にできますか?
2. なぜString不変なのですか？
3. 不変オブジェクトの利点/欠点は何ですか?
4. StringBuilderString やその逆よりも、変更可能なオブジェクトを優先する必要があるのはなぜですか?

(Java での) 良い例を示していただければ幸いです。

リレーショナル モデルの実装に使用できる永続的なデータ構造に関する資料を探しています。

不変のデータ構造の意味での永続性。

良いリソース、本、論文などを知っている人はいますか?

(私は既にPurely Functional Data Structuresという本を持っています。これは私が探しているものの良い例です。)

Java Bean に不変性を提供する可能性について非常に興味があります (ここでの Bean とは、メンバーにゲッターとセッターを提供する空のコンストラクターを持つクラスを意味します)。明らかに、これらのクラスは不変ではなく、データ層から値を転送するために使用される場所は、実際の問題のようです。

この問題に対する 1 つのアプローチは、StackOverflow で言及されている「C# の不変オブジェクト パターン」と呼ばれ、オブジェクトは完全にビルドされると凍結されます。私には別のアプローチがあり、それについて人々の意見を聞きたいと思っています。

パターンには Immutable と Mutable の 2 つのクラスが含まれ、Mutable と Immutable は両方とも、非変更 Bean メソッドを提供するインターフェースを実装します。

例えば

このアプローチにより、リフレクションを使用して (通常の慣例により) Bean を構築することができ、また、最も近い機会に不変のバリアントに変換することもできます。残念ながら、Bean ごとに明らかに大量のボイラープレートがあります。

この問題に対する他の人々のアプローチを聞くことに非常に興味があります。（良い質問を提供していないことをお詫びします。議論するのではなく、答えることができます:)

不変クラスの作成に取り組んでいます。
すべてのプロパティを読み取り専用としてマークしました。

クラスのアイテムのリストがあります。
ただし、プロパティが読み取り専用の場合、リストは変更できます。

リストの IEnumerable を公開すると、不変になります。
クラスを不変にするために従わなければならない基本的なルールは何ですか?

私の現在の OOP の状態の概念と、Haskell や Clojure のような関数型言語で行われる方法との違いを理解する助けが必要です。

ハックニーの例を使用するために、単純化された銀行口座オブジェクト/構造体/その他を扱っているとしましょう。OOP 言語では、BankAccount への参照を保持するクラスがあり、金利などのインスタンス変数と、オブジェクトの状態を変更し、通常は何も返さない setInterestRate() などのメソッドがあります。たとえば Clojure では、銀行口座の構造体 (美化されたハッシュマップ) と、銀行口座のパラメーターやその他の情報を受け取り、新しい構造体を返す特別な関数を用意します。したがって、元のオブジェクトの状態を変更する代わりに、必要な変更を加えた新しいオブジェクトが返されます。

それで...どうすればいいですか？古い銀行口座を参照していた変数を上書きしますか? もしそうなら、それは状態を変えるOOPアプローチよりも利点がありますか? 結局、どちらの場合も、必要な変更を加えたオブジェクトを参照する変数があるようです。私は遅れているので、何が起こっているのか漠然とした概念しか持っていません。

それが理にかなっていることを願っています。助けてくれてありがとう！