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

次のコード例には、部屋を表す不変オブジェクトのクラスがあります。北、南、東、および西は、他の部屋への出口を表します。 public sealed class Room { public Room(string name, Room northExit, Room southExit, Room eastExit, Room westExit) { this.Name = name; this.North = northExit; this.South = southExit; this.East = eastExit; this.West = westExit; } public string Name { get; } public Room North { get; } public Room South { …

24 c#  functional-programming  immutability  circular-dependency 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 閉じた3年前。 Reduxフレームワークは、不変の状態/純粋関数パラダイムを支持します。これは、現在のアクションに関して、前の状態から新しい状態の作成を促進します。このパラダイムの適用可能性は疑う余地がありません。 私の主な懸念は、Reduxレデューサーが呼び出されたアクションごとに以前の状態から新しい新しい状態を熱心に返すため、大量のメモリドレイン（メモリリークと混同しないでください）が多くの実際のアプリケーションで一般的に発生することです。Javascriptアプリケーションは通常、平均的なユーザーのデバイスのブラウザーで実行され、他のいくつかのデバイス固有のアプリケーションと、さらにいくつかのブラウザーのタブとウィンドウも実行できることを考慮すると、メモリを節約する必要性がますます明らかになります。 Reduxアプリケーションのメモリ消費量を従来のFluxアーキテクチャと実際に比較した人はいますか？もしそうなら、彼らは彼らの調査結果を共有できますか？

23 memory  immutability  memory-usage  reactjs 

不変の「パターン」はその長所から気に入っています。過去には、不変のデータ型（一部、ほとんど、またはすべて）を使用してシステムを設計することが有益であることがわかりました。多くの場合、そうすることで、作成するバグが少なくなり、デバッグがはるかに簡単になります。 しかし、私の仲間は一般的に不変を避けています。彼らはまったく経験がありません（それからはほど遠い）が、データオブジェクトを古典的な方法で書き込みます-すべてのメンバーのゲッターとセッターを持つプライベートメンバー。その後、通常、コンストラクターは引数をとらないか、単に便宜上いくつかの引数をとります。多くの場合、オブジェクトの作成は次のようになります。 Foo a = new Foo(); a.setProperty1("asdf"); a.setProperty2("bcde"); たぶん彼らはそれをどこでもします。たぶん、それらがどれほど重要であっても、それらの2つの文字列を受け取るコンストラクタを定義することすらありません。そして多分、それらは後でそれらの文字列の値を変更せず、変更する必要はありません。明らかに、これらのことが真実であれば、オブジェクトは不変として設計されるでしょう。（コンストラクターは2つのプロパティを取り、セッターはまったく取りません）。 オブジェクト型を不変として設計する必要があるかどうかをどのように決定しますか？判断するための適切な基準はありますか？ 私は現在、自分のプロジェクトのいくつかのデータ型を不変に切り替えるかどうかを議論していますが、ピアにそれを正当化する必要があり、型のデータは（めったに）変更されない可能性があります-いつでも変更できますそれは不変の方法です（新しいものを作成し、変更したいものを除いて古いオブジェクトからプロパティをコピーします）。しかし、これが単に不変物が透けて見えるのが私の愛なのか、それとも実際にそれらの必要性/利益があるのか​​はわかりません。

23 design  immutability 

DDDを使用するシステム（およびORMを使用するすべてのシステム）を検討してください。ほぼすべてのユースケースで、現実的にシステムのポイントは、これらのドメインオブジェクトを操作することです。それ以外の場合、実際の効果や目的はありません。 不変オブジェクトを変更すると、オブジェクトが永続化された後に新しいレコードが生成され、データソースに大量の膨張が発生します（変更後に以前のレコードを削除しない限り）。 不変オブジェクトを使用することの利点はわかりますが、この意味では、不変オブジェクトを使用する便利なケースはありません。これは間違っていますか？

18 immutability  domain-driven-design 

OOPのバックグラウンド（Java）から来て、私は自分でScalaを学んでいます。不変オブジェクトを個別に使用することの利点はすぐにわかりますが、そのようなアプリケーション全体をどのように設計できるかを見るのは大変です。例を挙げます。 「マテリアル」とそれらのプロパティを表すオブジェクト（ゲームを設計しているので、実際にその問題を抱えている）があり、たとえば水や氷があるとします。このようなすべてのマテリアルインスタンスを所有する「マネージャー」がいます。1つの特性は、凝固点と融点、および材料が凍結または融解するものです。 [編集]すべてのマテリアルインスタンスは「シングルトン」で、Java Enumのようなものです。 「水」は0℃で「氷」に凍結し、「氷」は1℃で「水」に融解すると言います。しかし、水と氷が不変である場合、それらの1つを最初に作成する必要があり、コンストラクターパラメーターとしてまだ存在しない他のものへの参照を取得できなかったため、コンストラクターパラメーターとして相互参照を取得できません。両方のマネージャーへの参照を提供することでこれを解決することができますので、彼らは凍結/融解特性を求められるたびに必要な他の材料インスタンスを見つけるためにクエリすることができますが、マネージャー間で同じ問題が発生しますそして、それらはお互いへの参照を必要としますが、それらのうちの1つのコンストラクターでのみ提供できるため、マネージャーまたはマテリアルは不変にできません。 彼らはこの問題を回避する方法がないのですか、それとも「機能的な」プログラミング技術、またはそれを解決するための他のパタ​​ーンを使用する必要がありますか？

17 design-patterns  immutability 

データモデルを保持するクラスを設計するとき、不変オブジェクトを作成すると便利ですが、どの時点でコンストラクターパラメーターリストとディープコピーの負荷が大きくなりすぎて、不変の制限を放棄する必要があるのでしょうか？ たとえば、名前付きのものを表す不変のクラスを次に示します（C＃構文を使用していますが、原則はすべてのOO言語に適用されます） class NamedThing { private string _name; public NamedThing(string name) { _name = name; } public NamedThing(NamedThing other) { this._name = other._name; } public string Name { get { return _name; } } } 名前付きのものは、新しい名前付きのものに作成、クエリ、コピーできますが、名前は変更できません。 これはすべて良いですが、別の属性を追加したい場合はどうなりますか？コンストラクターにパラメーターを追加し、コピーコンストラクターを更新する必要があります。これはあまり手間がかかりませんが、複雑なオブジェクトを不変にしたいときに、問題が発生するのはわかります。 クラスに他の複雑なクラスを含むmay属性とコレクションが含まれている場合、コンストラクターのパラメーターリストは悪夢のように思えます。 では、どの時点でクラスが複雑すぎて不変にならないのでしょうか？

16 class-design  immutability 

私は最近、不変オブジェクトの有用性につまずきました。たとえば、要素をコンストラクタに渡し、クラスを不変にする必要がある場合、これらの要素が不変でない場合はこれらの要素をコピーする必要があります。 これには、プロジェクトに関する多くの確認または知識が必要です。 public A(B foo) かつB不変ではない、A私はコピーする必要があるだろうB。今でBは不変のように思えますが、それ自体はコンストラクタなどに可変クラスを持っています。 Javaでクラスが不変である場合、文書化するための標準またはベストプラクティスはありますか？@immutableJavadoc にはキーワードがないようです。 @Immutable注釈は自動クラスの生成ではなく、標準のJavaの一部については全く違うもののようです。

14 java  documentation  immutability 

SOからの質問に触発された：https : //stackoverflow.com/questions/6623391/how-to-gain-control-of-a-5gb-heap-in-haskell FPの多くの長所と短所については長い議論の余地がありますが、現時点では、最新のハードウェアでのFPの主な効率に範囲を絞りたいと思います。 定説： 機能的パラダイムは不変性とステートレス（？）を意味しますが、機能的プログラムを実行するハードウェアはステートフルな有限オートマトンです。「純粋な機能」プログラムを「ステートフルなハードウェア」表現に変換すると、プログラマーはほとんど制御できず、オーバーヘッド（？）が発生し、ハードウェア機能の使用が制限されます（？）。 私は疑問の声明で正しいか間違っていますか？ FPは、現代の汎用コンピューターアーキテクチャでの主要なパフォーマンスペナルティを意味する/しないことを証明できますか？ 編集： いくつかのコメントに応じて既に述べたように、質問は実装のパフォーマンスと詳細に関するものではありません。これは、プリンシパルオーバーヘッドの有無に関するものであり、ステートフルオートマトンでFPを実行するともたらされる可能性があります。

14 performance  functional-programming  hardware  immutability  state 

List（：+）の追加操作の実行時間は、のサイズに比例して増加することを読みましたList。 に追加することListは、かなり一般的な操作のようです。なぜこれを行う慣用的な方法がコンポーネントを前に付けてからリストを逆にする必要があるのですか？実装はいつでも変更される可能性があるため、設計の失敗にもなりません。 私の観点からは、先頭と末尾の両方がO（1）である必要があります。 これには正当な理由がありますか？

13 language-design  scala  list  immutability 

私はオブジェクト指向プログラミングに慣れていないので、把握に時間がかかっている概念の1つは不変性です。昨夜電球が消えたと思うが、確認したい： 不変オブジェクトを変更できないというステートメントに出くわすと、たとえば次のようなことができるため困惑します。 NSString *myName = @"Bob"; myName = @"Mike"; そこで、不変型NSStringのmyNameを変更しました。私の問題は、「オブジェクト」という言葉がメモリ内の物理オブジェクト、または抽象化「myName」を指すことがあるということです。前者の定義は、不変性の概念に適用されます。 変数については、不変性のより明確な（私にとって）定義は、不変オブジェクトの値は、メモリ内の位置、つまり参照（ポインタとも呼ばれる）を変更することによってのみ変更できるということです。 これは正しいですか、それとも私はまだ森の中で迷っていますか？

13 object-oriented  objective-c  immutability 

どのように私は、次のすべてを持っているシステムを構築します。 不変オブジェクトで純粋な関数を使用します。 関数が必要とする関数データのみに渡し、それ以上（つまり、大きなアプリケーション状態オブジェクトはなし） 関数への引数が多すぎることは避けてください。 関数に渡されるパラメーターが多すぎるのを避けるために、関数にパラメーターをパックおよびアンパックするためだけに新しいオブジェクトを作成する必要はありません。複数のアイテムを単一のオブジェクトとして関数にパックする場合、一時的に構築されたものではなく、そのオブジェクトをそのデータの所有者にしたい Stateモナドはルール2に違反しているように思えますが、モナドを介して織り込まれているため明らかではありません。 どういうわけかレンズを使用する必要があると感じていますが、非機能言語についてはほとんど書かれていません。 バックグラウンド 演習として、既存のアプリケーションの1つをオブジェクト指向スタイルから機能スタイルに変換しています。私が最初にやろうとしているのは、アプリケーションの内部コアをできるだけ多く作成することです。 私が聞いたことの1つは、純粋に機能的な言語で「状態」を管理する方法であり、これは私がステートモナドによって行われていると信じていることです。 「そのままの世界」を選択し、関数が戻ると、変化した世界の状態を返します。 たとえば、純粋に機能的な方法で「hello world」を実行する方法は、プログラムに画面の状態を渡し、「hello world」が印刷された画面の状態を受け取るようなものです。技術的には、純粋な関数を呼び出しているので、副作用はありません。 それに基づいて、アプリケーションを調べました。1。最初に、すべてのアプリケーション状態を単一のグローバルオブジェクト（GameState）に入れます。2。次に、GameStateを不変にしました。変更することはできません。変更が必要な場合は、新しいものを作成する必要があります。これを行うために、コピーコンストラクターを追加しました。オプションで、変更された1つ以上のフィールドを使用します。3.各アプリケーションに、GameStateをパラメーターとして渡します。関数内で、予定通りの処理を行った後、新しいGameStateを作成して返します。 純粋に機能的なコアと、そのGameStateをアプリケーションのメインワークフローループにフィードする外側のループの仕組み。 私の質問： さて、私の問題は、GameStateには約15種類の不変オブジェクトがあることです。最下位レベルの関数の多くは、スコアの保持など、これらのオブジェクトの一部のみで動作します。それで、スコアを計算する関数があるとしましょう。今日、GameStateはこの関数に渡され、新しいスコアで新しいGameStateを作成してスコアを変更します。 それについて何かが間違っているようです。この関数はGameState全体を必要としません。スコアオブジェクトが必要です。そこで、スコアを渡すように更新し、スコアのみを返します。 それは理にかなっているように思えたので、私は他の機能をさらに使いました。一部の関数では、GameStateから2、3、または4つのパラメーターを渡す必要がありますが、アプリケーションの外側のコア全体でパターンを使用しているため、ますます多くのアプリケーション状態を渡しています。たとえば、ワークフローループの先頭で、メソッドを呼び出し、メソッドを呼び出すメソッドなどを呼び出して、スコアが計算されるまで続けます。つまり、一番下の関数がスコアを計算するという理由だけで、現在のスコアがこれらすべてのレイヤーに渡されます。 だから今私は時々数十のパラメータを持つ関数を持っています。これらのパラメーターをオブジェクトに入れてパラメーターの数を減らすこともできますが、そのクラスは、単に渡すことを避けるために呼び出し時に単純に構築されるオブジェクトではなく、状態アプリケーション状態のマスターの場所にしたいです複数のパラメータで、それらを解凍します。 だから今、私が持っている問題は私の関数があまりにも深くネストされていることだろうかと思っています。これは小さな関数が必要なためです。そのため、関数が大きくなったらリファクタリングし、複数の小さな関数に分割します。しかし、そうすることでより深い階層が生成され、外部関数が直接それらのオブジェクトを操作していない場合でも、内部関数に渡されたものはすべて外部関数に渡される必要があります。 この問題を回避する方法に沿って単にGameStateを渡すように見えました。しかし、関数が必要とする以上の情報を関数に渡すという元の問題に戻りました。

12 c#  functional-programming  immutability  state  monad 

私はC ++で不変オブジェクトの使用を練習しています。私の個人的な目標は、一連の不変グラフで（ヒープ内の）汎用オブジェクトグラフを表現することです。 マルチバージョングラフ自体の作​​成はそれほど難しくありません。問題はパフォーマンスです。ブルートフォースバージョン管理にはグラフの完全なコピーが必要であり、これは受け入れられませんでした。 変更されていないノードを共有しようとしました。しかし、この場合、新しい問題が発生しました。参照。他のオブジェクトへの参照は、グラフ全体で更新する必要があります。これは、新しいグラフバージョンを導出するたびにすべてのノードを訪問する必要があります。また、これによりノードが参照で変更されるため、ノードも（コピーすることによって）派生する必要があります。総当たりコピーよりもパフォーマンスはそれほど良くありません。 私が想像できる限り、オブジェクトグラフの変化を不変状態で表現するための実際の効率的な方法はありません。だから私はこれに関するいくつかのアイデアを求めています。 不変状態でオブジェクトグラフの突然変異を効率的に表現することは可能ですか？

12 graph  immutability 

最近、シングルトンに対する何らかの革命がありましたが、それらがステートレスである場合、シングルトンに何か問題がありますか？ 私は酷使の話とすべてを知っています...これはシングルトンだけでなくすべてに適用されます。

12 design-patterns  object-oriented  singleton  immutability 

私はFPで不変データを扱うことを理解しようとしています（特にF＃ですが、他のFPも大丈夫です）、ステートフル思考（OOPスタイル）の古い習慣を破ります。ここでの質問に対する選択された回答の一部は、OOPのステートフルな表現とFPの不変な表現（たとえば、プロデューサーとコンシューマーのキュー）によって解決される問題に関する記述の検索を繰り返しました。何か考えやリンクは大歓迎ですか？前もって感謝します。 編集：質問をもう少し明確にするために、FPで複数のスレッド（例：プロデューサーとコンシューマー）で不変の構造（例：キュー）を同時に共有する方法

12 f#  functional-programming  immutability 

クラスのインスタンスが変更されることを期待されていないとき、私はますます不変の型を使用しているようです。より多くの作業が必要になります（以下の例を参照）が、マルチスレッド環境での型の使用が簡単になります。 同時に、可変性がだれにも利益をもたらさない場合であっても、他のアプリケーションで不変型が表示されることはほとんどありません。 質問：不変の型が他のアプリケーションで使用されることがほとんどないのはなぜですか？ これは、不変型のコードを書くのが長いためです。 または、私は何かを見逃していて、不変の型を使用するときにいくつかの重要な欠点がありますか？ 実生活からの例 WeatherそのようなRESTful APIから取得するとしましょう。 public Weather FindWeather(string city) { // TODO: Load the JSON response from the RESTful API and translate it into an instance // of the Weather class. } 一般的に表示されるのは次のとおりです（コードを短縮するために新しい行とコメントが削除されています）。 public sealed class Weather { public City CorrespondingCity { get; set; } public SkyState …

12 c#  immutability