タグ付けされた質問 「immutability」

不変オブジェクト¹が優れたシンプルなものであり、並行プログラミングでメリットがある場合、プログラマーはなぜ可変オブジェクトを作成し続けるのですか？ 私はJavaプログラミングで4年の経験があり、それを見ると、クラスを作成した後に最初に行うことは、IDEでゲッターとセッターを生成することです（したがって、変更可能になります）。認識不足がありますか、ほとんどのシナリオで可変オブジェクトを使用しても問題ありませんか？ ¹ 不変オブジェクトとは、作成後に状態を変更できないオブジェクトです。 ² 可変オブジェクトは、作成後に変更できるオブジェクトです。

250 object-oriented  immutability 

Javaチームは、Java 8の関数型プログラミングの障壁を取り除くために多大な努力をしてきました。特に、java.utilコレクションの変更は、変換を非常に高速なストリーム操作に連鎖させるという素晴らしい仕事をしています。彼らがコレクションにファーストクラスの関数と機能メソッドを追加するのをどれだけうまくやったかを考えると、なぜ彼らは不変のコレクションや不変のコレクションのインターフェースを提供することに完全に失敗したのでしょうか？ 既存のコードを変更せずに、Javaチームはいつでも変更可能なインターフェイスと同じ不変インターフェイスを追加し、「set」メソッドを削除して、既存のインターフェイスを次のように拡張できます。 ImmutableIterable ____________/ | / | Iterable ImmutableCollection | _______/ / \ \___________ | / / \ \ Collection ImmutableList ImmutableSet ImmutableMap ... \ \ \_________|______________|__________ | \ \___________|____________ | \ | \___________ | \ | \ | List Set Map ... 確かに、List.add（）やMap.put（）などの操作は現在、指定されたキーのブール値または前の値を返し、操作が成功したか失敗したかを示します。不変のコレクションは、そのようなメソッドをファクトリーとして扱い、追加された要素を含む新しいコレクションを返す必要があります-これは現在の署名と互換性がありません。ただし、ImmutableList.append（）または.addAt（）およびImmutableMap.putEntry（）などの別のメソッド名を使用することで回避できます。結果として得られる冗長性は、不変のコレクションを操作する利点よりも重要であり、型システムは間違ったメソッドを呼び出すエラーを防ぎます。時間が経つにつれて、古いメソッドは廃止される可能性があります。 不変コレクションの勝利： シンプルさ-基礎となるデータが変更されない場合、コードについての推論は簡単です。 ドキュメンテーション-メソッドが不変のコレクションインターフェイスを取る場合、そのコレクションを変更しないことを知っています。メソッドが不変のコレクションを返す場合、変更できないことを知っています。 並行性-不変コレクションはスレッド間で安全に共有できます。 不変性を前提とする言語を味わった人として、Wild延する突然変異のワイルドウエストに戻ることは非常に困難です。Clojureのコレクション（シーケンス抽象化）には、Java …

130 java  history  immutability  collections 

JavaScriptでは、データ構造を不変として扱う最近の傾向があるようです。たとえば、オブジェクトの単一のプロパティを変更する必要がある場合は、新しいプロパティを使用して新しいオブジェクト全体を作成し、古いオブジェクトから他のすべてのプロパティをコピーして、古いオブジェクトをガベージコレクトしてください。（とにかく私の理解です。） 私の最初の反応は、パフォーマンスに悪いように聞こえます。 しかし、Immutable.jsやRedux.jsのようなライブラリは、私よりも賢い人によって書かれており、パフォーマンスに強い関心を持っているようです。そのため、ガベージ（およびパフォーマンスへの影響）の理解が間違っているのではないかと思います。 私が見逃している不変性にパフォーマンス上の利点はありますか？

88 javascript  performance  immutability 

その理由を理解できませんでした。私は常に他の開発者のようにStringクラスを使用しますが、その値を変更すると、Stringの新しいインスタンスが作成されます。 JavaのStringクラスの不変性の理由は何ですか？ StringBufferやStringBuilderのような代替手段があることを知っています。それは単なる好奇心です。

78 java  programming-languages  language-design  strings  immutability 

Javaコレクションフレームワークを拡張する最初の実装中に、オプションとして宣言されたメソッドがコレクションインターフェイスに含まれているのを見て驚いた。実装者は、サポートされていない場合、UnsupportedOperationExceptionsをスローすることが期待されています。これはすぐに、貧弱なAPIデザインの選択肢として私を驚かせました。 Joshua Blochの優れた「Effective Java」の本を多く読んだ後、彼がこれらの決定に責任を負う可能性があることを知った後、本で支持されている原則と一致しなかったようです。コレクションと、「オプション」メソッドでコレクションを拡張するMutableCollectionの2つのインターフェイスを宣言すると、はるかに保守性の高いクライアントコードにつながると思います。 ここに問題の優れた要約があります。 2つのインターフェイスの実装の代わりにオプションのメソッドが選択された理由はありますか？

69 java  design  api  immutability 

私はakkaで毎日7〜8か月働いています。私が始めたとき、私はアプリケーションに取り組んでおり、ほとんどのオブジェクト間で通信するために、アクターは基本的にアクターシステム内のどこででも使用されることに気付きました。だから私は同じことをした-x / y / zの別のアクターをスピンアップする。 これはあまりにも無差別で、必要のないところに複雑さを加えているように思えます-しかし、アクターとプレーンを介した同期、または先物を介した非同期ロジックを使用する必要がある場所についての議論は見つかりません。同僚が似たようなことを言った後、私は自分のスタンスを熟考し始めました。最近、タスクを熟考し、不変の実装で同じ結果を安全に達成できるため、別のアクターの作成を避けたいくつかのケースを実現しました。たとえば、非常に頻繁にアクセスするデータベースまたはファイルから設定値を取得するようなものです結果を待つのが実際のユースケースです。 特に、不変の状態で遊んでいる場合、アクターは複雑さを生み出し、スループットを制限します。たとえば、オブジェクトの純粋な関数は、並行性のレベルを問わず、リスクなしで同時に呼び出すことができます。アクターは一度に1つのメッセージしか処理できません。別の考慮事項は、futureの使用を開始しない限り、結果を待つ必要がある場合にスレッドを保留することですが、非同期メッセージングやスケールを心配する必要がない場合は、アクターを採用するのはやり過ぎかもしれません。 だから私の質問は-俳優を使用するのに悪い時間はありますか？アーランがどのように見えるのか興味があり、他の人の洞察が本当に欲しいです。または、アクターの使用に関するいくつかの原則がある場合。

58 scala  complexity  erlang  immutability  akka 

不変の型、特にコレクションを使用する主な利点として、スレッドセーフが常に/しばしば言及されているようです。 メソッドが文字列の辞書（C＃では不変）を変更しないようにしたい状況があります。できるだけ物事を制約したいと思います。 ただし、新しいパッケージ（Microsoft Immutable Collections）に依存関係を追加する価値があるかどうかはわかりません。パフォーマンスも大きな問題ではありません。 したがって、私の質問は、ハードパフォーマンス要件がなく、スレッドセーフの問題がない場合に、不変コレクションを強く推奨するかどうかだと思いますか？値のセマンティクス（私の例のように）も要件である場合とそうでない場合があることを考慮してください。

53 immutability  semantics  collections  mutable 

私はSmalltalkの初期の歴史を読んでおり、その意味の理解に疑問を抱かせる「割り当て」についての言及がいくつかあります。 OOPは多くの動機から来ましたが、2つが中心でした。大規模なものは詳細の隠蔽を伴う複雑なシステムのためのより良いモジュールスキームを見つけることであり、小規模なものは割り当てのより柔軟なバージョンを見つけることであり、それからそれを完全に排除しようとしました。 （1960-66から-初期のOOPおよび60年代のその他の形成的アイデア、セクションI） Simulaから得たのは、バインディングと割り当てを目標に置き換えることができるということです。プログラマーに最後に望むことは、たとえ比fig的に提示されたとしても、内部状態を混乱させることです。代わりに、オブジェクトは、動的コンポーネントとしての使用により適した、より高いレベルの動作のサイトとして提示される必要があります。（...）残念なことに、今日「オブジェクト指向プログラミング」と呼ばれるものの多くが、より洗練された構成要素を備えた単純な古いスタイルのプログラミングである。多くのプログラムには、より高価な添付プロシージャによって実行される「割り当てスタイル」操作がロードされています。 （「オブジェクト指向」スタイル、セクションIVから） オブジェクトがファサードであり、オブジェクトにインスタンス変数を設定することを目的とするメソッド（または「メッセージ」）（つまり「割り当て」）が目的に反しているという意図を解釈するのは正しいですか？この解釈は、セクションIVの後半の2つのステートメントでサポートされているようです。 永続状態、ポリモーフィズム、インスタンス化、およびオブジェクトの目標としてのメソッドの4つの手法が一緒に使用され、多くの権限を占めています。これらのいずれも「オブジェクト指向言語」を採用する必要はありません--ALGOL 68はほとんどこのスタイルに変えることができます-そして、OOPLは単に特定の実りある方向にデザイナーの心を集中させます。ただし、カプセル化を正しく行うことは、状態の抽象化だけでなく、プログラミングから状態指向のメタファーを排除することを約束するものです。 ...そして： 割り当てステートメントは、抽象的なものであっても、非常に低いレベルの目標を表します。何かを成し遂げるためには、それらの多くが必要になります。一般に、シミュレートされているかどうかに関係なく、プログラマが状態をいじり回すことは望ましくありません。 ここでは、不透明で不変のインスタンスが推奨されていると言ってもいいでしょうか？または、推奨されていない単純な状態変更ですか？私が持っている場合たとえば、BankAccountクラスを、それが持ってOKだGetBalance、DepositとWithdrawインスタンスメソッド/メッセージ。SetBalanceインスタンスメソッド/メッセージがないことを確認してください？

47 object-oriented  immutability  smalltalk  functional-programming 

ほとんどのOOP言語では、オブジェクトは通常、限られた例外セット（たとえば、Pythonのタプルや文字列など）を使用して変更可能です。ほとんどの関数型言語では、データは不変です。 可変オブジェクトと不変オブジェクトの両方が、独自の長所と短所の完全なリストをもたらします。 たとえば、（明示的に宣言された）可変データと不変データがあるscalaのような両方の概念を結合しようとする言語があります（間違っている場合は修正してください、scalaの知識は限られています）。 私の質問は次のとおりです。完全な（原文のまま！）不変性-つまり、オブジェクトが作成された後はオブジェクトを変更できません-は、OOPコンテキストで意味をなしますか？ そのようなモデルの設計または実装はありますか？ 基本的に、（完全な）不変性とOOPは反対ですか、それとも直交ですか？ 動機：OOPでは通常、データを操作し、基礎となる情報を変更（変更）し、それらのオブジェクト間の参照を保持します。たとえば、別のオブジェクトを参照Personするメンバーを持つクラスのオブジェクト。父親の名前を変更すると、更新の必要なく、これはすぐに子オブジェクトに表示されます。不変なので、父と子の両方に新しいオブジェクトを構築する必要があります。ただし、共有オブジェクト、マルチスレッド、GILなどを使用すると、kerfuffleがはるかに少なくなります。fatherPerson

43 object-oriented  immutability 

パート1 明らかに不変性は、マルチプロセッサプログラミングでのロックの必要性を最小限に抑えますが、その必要性を排除しますか、または不変性だけでは不十分な場合がありますか？ほとんどのプログラムが実際に何かを行う（データストアを更新する、レポートを作成する、例外をスローするなど）前に処理を延期し、状態をカプセル化できるのは私だけのようです。そのようなアクションは常にロックなしで実行できますか？元のオブジェクトを変更するのではなく、各オブジェクトを破棄して新しいオブジェクトを作成するという単純なアクション（不変性の大まかな見方）は、プロセス間競合からの絶対的な保護を提供しますか、それともロックが必要なコーナーケースがありますか？ 私は多くの機能的なプログラマーと数学者が「副作用なし」について話すのを好むことを知っていますが、「現実の世界」では、機械命令を実行する時間であっても、すべてに副作用があります。理論的/学術的答えと実用的/現実世界の答えの両方に興味があります。 特定の境界または仮定が与えられれば、不変性が安全であれば、「安全ゾーン」の境界が正確に何であるかを知りたいです。可能な境界のいくつかの例： I / O 例外/エラー 他の言語で書かれたプログラムとの相互作用 他のマシンとの相互作用（物理、仮想、または理論） この質問を始めたコメントに対して@JimmaHoffaに感謝します！ パート2 多くの場合、マルチプロセッサプログラミングは最適化手法として使用され、コードの実行を高速化します。ロックと不変オブジェクトを使用する方が速いのはいつですか？ アムダールの法則で定められた制限を考えると、不変オブジェクトと可変オブジェクトのロックで全体的なパフォーマンスを向上させることができます（ガベージコレクターの有無にかかわらず）。 概要 これら2つの質問を1つにまとめて、スレッド化の問題の解決策として不変性の境界ボックスがどこにあるのかを探ろうとしています。

39 functional-programming  multithreading  synchronization  immutability  locks 

私はよく用語immutableを見て、const同じ意味で使用しました。ただし、私の（小さな）経験から、この2つは、コードで作成する「契約」が大きく異なります。 Immutableは、このオブジェクトがまったく変更されないという契約を作成します（Pythonタプル、Java文字列など）。 Constは、この変数のスコープ内では変更されないという契約を結んでいます（この期間中にC / C ++キーワードなどが指し示すオブジェクトに対して他のスレッドが何をするかについての約束はありません）。 明らかに、言語がシングルスレッド（PHP）であるか、線形または一意のタイピングシステム（Clean、Mercury、ATS）を持たない限り、2つは同等ではありません。 最初に、これら2つの概念の理解は正しいですか？ 第二に、違いがある場合、なぜそれらはほとんど排他的に交換可能に使用されるのですか？

28 terminology  immutability  const 

不変オブジェクトのインターフェイスを宣言しないでください [編集] 問題のオブジェクトがデータ転送オブジェクト（DTO）またはプレーンオールドデータ（POD）を表す場合 それは合理的なガイドラインですか？ これまで、不変の（データを変更できない）シールクラスのインターフェイスを作成することがよくありました。私は、不変性を気にするところにはインターフェースを使用しないように注意しました。 残念ながら、インターフェイスはコードに浸透し始めます（心配しているのは私のコードだけではありません）。インターフェースを渡された後、渡されるものが不変であると本当に想定したいコードにそれを渡したいと思うでしょう。 この問題のため、不変オブジェクトのインターフェイスを宣言しないことを検討しています。 これは単体テストに関して悪影響があるかもしれませんが、それ以外に、これは合理的なガイドラインに思えますか？ または、私が見ている「拡散インターフェース」の問題を回避するために使用すべき別のパターンがありますか？ （私はこれらの不変オブジェクトをいくつかの理由で使用しています：主にスレッドセーフのために、私は多くのマルチスレッドコードを書いていますが、それはまた、メソッドに渡されるオブジェクトの防御的なコピーの作成を避けることができるためです。コードは何かが不変であることを知っている多くの場合-インターフェイスを渡された場合はそうではありません。実際、インターフェイスを介して参照されるオブジェクトの防御コピーを作成することさえできません。クローン操作またはそれをシリアル化する方法...） [編集] オブジェクトを不変にしたいという私の理由により多くのコンテキストを提供するには、Eric Lippertの次のブログ投稿を参照してください。 http://blogs.msdn.com/b/ericlippert/archive/tags/immutability/ また、ここでは、マルチスレッドジョブキューで操作/受け渡しされるアイテムなど、いくつかの低レベルの概念で作業していることを指摘する必要があります。これらは本質的にDTOです。 また、Joshua Bloch は、著書Effective Javaで不変オブジェクトの使用を推奨しています。 ファローアップ フィードバックをありがとう、すべて。先に進み、このガイドラインをDTOとその同類に使用することにしました。これまでのところ順調に機能していますが、1週間しか経っていません...それでも、見栄えは良いです。 これに関連する他の問題がいくつかあります。特に私が「ディープまたはシャロー不変性」と呼んでいるもの（ディープアンドシャロークローンから盗んだ命名法）-しかし、それはまた別の質問です。

27 c#  immutability 

単一リンクリストを作成することにし、内部リンクノード構造を不変にする計画を立てました。 しかし、私は思わぬ障害に遭遇しました。次のリンクされたノード（以前のadd操作から）があるとします。 1 -> 2 -> 3 -> 4 を追加したいと言います5。 これを行うには、ノード4は不変なので、の新しいコピーを作成する必要があります4が、そのnextフィールドをを含む新しいノードに置き換えます5。問題は3、古いものを参照していること4です。追加されていないもの5。今、コピーし3、そのnextフィールドを置き換えて4コピーを参照する必要がありますが、今2は古いものを参照してい3ます... または、言い換えると、追加を行うには、リスト全体をコピーする必要があるようです。 私の質問： 私の考えは正しいですか？構造全体をコピーせずに追加を行う方法はありますか？ どうやら「効果的なJava」には推奨事項が含まれています。 クラスを変更可能にする非常に正当な理由がない限り、クラスは不変でなければなりません... これは可変性の良いケースですか？ 私はリスト自体について話していないので、これは提案された答えの複製ではないと思います。これは明らかに、インターフェイスに準拠するために変更可能でなければなりません（新しいリストを内部に保持し、getterを介して取得するなどの操作を行わないでください。リストの内部が不変でなければならないかどうかについて話している。

26 java  immutability  linked-list 

Joshua BlochのEffective Javaの項目の1つは、クラスがインスタンスの変更をできる限り少なくし、できればまったく許可しないという概念です。 多くの場合、オブジェクトのデータは何らかの形式のデータベースに保存されます。これにより、特に大規模システム内の単一のエンティティを表すテーブルについて、データベース内の不変性の考えを考えるようになりました。 私が最近実験しているのは、これらのオブジェクトを表すテーブル行に対して行う更新を最小限に抑え、可能な限り挿入を実行しようとするアイデアです。 最近試したものの具体例。後で追加データを含むレコードを追加する可能性があることがわかっている場合は、それを表す別のテーブルを作成します。次の2つのテーブル定義のようなものです。 create table myObj (id integer, ...other_data... not null); create table myObjSuppliment (id integer, myObjId integer, ...more_data... not null); これらの名前が逐語的ではなく、単にアイデアを示すためであることは、願わくば明白です。 これは、データ永続性モデリングへの合理的なアプローチですか？特に、レコードが最初に作成されたときに存在しなかった可能性のあるデータのNULLを埋めるために、テーブルで実行される更新を制限することを試みる価値はありますか？このようなアプローチが後に激しい痛みを引き起こす可能性があるときはありますか？

26 database-design  immutability 

2つのreadonly intフィールドを持つクラスがあります。プロパティとして公開されます： public class Thing { private readonly int _foo, _bar; /// <summary> I AM IMMUTABLE. </summary> public Thing(int foo, int bar) { _foo = foo; _bar = bar; } public int Foo { get { return _foo; } set { } } public int Bar { get { return …

25 c#  object-oriented  immutability  properties