blocks|key|4504273|text|简单地说:一旦创建了一个不可变的对象，就无法更改该对象的内容。.Net不可变对象的示例包括字符串和Uri。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4504274|当你修改一个字符串时，你只是得到了一个新的字符串。原始字符串不会更改。Uri只有只读属性，没有可用于更改Uri内容的方法。|4504275|不可变对象很重要的情况多种多样，而且在大多数情况下都与安全性有关。Uri就是一个很好的例子。(例如，您不希望Uri被某些不受信任的代码更改。)这意味着您可以传递对不可变对象的引用，而不必担心内容会发生变化。|4504276|希望这能有所帮助。|4504277|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

To put it simple: Once you create an immutable object, there's no way to change the contents of that object. Examples of .Net immutable objects are String and Uri. 

When you modify a string, you simply get a new string. The original string will not change. An Uri has only readonly properties and no methods available to change the content of the Uri. 

Cases that immutable objects are important are various and in most of the cases have to do with security. The Uri is a good example here. (e.g. You don't want a Uri to be changed by some untrusted code.) This means you can pass a reference to a immutable object around without having to worry the contents will ever change. 

Hope this helps.

blocks|key|4504310|text|不可变对象是你可以放心地假设它不会改变的东西；它有一个重要的属性，每个使用它的人都可以假设他们看到的是相同的值。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4504311|不变性通常还意味着您可以将对象视为一个“值”，并且对象的相同副本和对象本身之间没有有效的区别。|4504312|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

An immutable object is something which you can safely assume isn't going to change; it has the important property that everyone using it can assume they're seeing the same value.

Immutability usually also means you can think of the object as being a "value", and that there's no effective difference between identical copies of the object and the object itself.

blocks|key|1081010|text|听着，我还没有看过你发布的链接。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1081011|然而，这是我的理解。|1081012|每个程序都有一些关于它的数据(状态)的知识，这些知识可以通过用户输入/外部更改等方式进行更改。|1081013|变量(改变的值)被保留以维护状态。不可变意味着某些数据是不变的。你可以说，它在某种程度上等同于只读或常量(可以这样理解)。|1081014|AFAIK，函数式编程有不可变的东西(例如，你不能使用赋值给一个保存值的变量。你可以做的是创建另一个变量，它可以保存原始值%2B更改)。|1081015|.net有一个string类，这是一个例子。|1081016|也就是说，你不能修改字符串的位置|1081017|string+s=+"hello"；我可以写s.Replace("el"，"a")；但这不会修改变量s的内容。|1081018|我能做的是s=+s.Replace("el"，"a")；|1081019|这将创建一个新变量并将其值赋给s(覆盖s的内容)。|1081020|专家可以纠正错误，如果我有，在我的理解。|1081021|编辑:+Immutable+=不可分配，一旦它保持了一些值，就不能被替换(也许？)|1081022|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|10|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|11|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|12|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|13|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|14|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|15|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|16|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|17|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|18|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|19|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1A|8|@]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]]|Y|$]]

Look, I haven't read the links that you have posted.

However, here is my understanding. 
Every program holds some knowledge of it's data (State), which can change either by user-input/external changes etc.

Variables (values which change) are kept to maintain state.
Immutable means some data which doesn't change. You can say, it is same as readonly or constant in some way (it can be seen it that way).

AFAIK, functional programming has things immutable (i.e. you cannot use assignment to a variable holding the value. What you can do is create another variable which can hold the original value + changes).

.net has string class which is an example. 
i.e. You can't modify string in its place

string s = "hello";
I can write s.Replace("el", "a"); But this won't modify the contents of variable s.

What I can do is
s = s.Replace("el","a"); 
This will create a new variable &amp; assign its value to s (overwriting content of s).

Experts can correct mistakes if I have, in my understanding.

EDIT: Immutable = Unassignable once it is holding some value &amp; can't be replaced in place (maybe?)

blocks|key|4504406|text|不变的东西永远不会变。可变的东西是可以改变的。易变的东西会发生变异。不可变的东西看起来会改变，但实际上创建了一个新的可变的东西。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4504407|例如，以下是Clojure中的地图|4504408|(def+imap+{1+"1"+2+"2"})
(conj+imap+[3+"3"])
(println+imap)|code-block|syntax|javascript|4504409|第一行创建了一个新的不可变的Clojure映射。第二行将3和"3“连接到地图。这可能看起来像是在修改旧的map，但实际上它返回的是一个添加了3+"3“的新map。这是不变性的最好的例子。如果这是一个可变的映射，它会简单地添加3+"3“直接到相同的旧映射。第三行打印地图|offset|length|style|BOLD|4504410|{3+"3",+1+"1",+2+"2"}|4504411|不变性有助于保持代码的整洁和安全。这就是为什么函数式编程语言倾向于不变性和较少的状态性的原因。|4504412|entityMap^0|0|0|0|3B|1|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|W|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|X|8|@$K|Y|L|Z|M|N]]|9|@]|A|$]]|$1|O|3|P|5|F|7|10|8|@]|9|@]|A|$G|H]]|$1|Q|3|R|5|6|7|11|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|T|$]]

Things that are immutable never change. Mutable things can change. Mutable things mutate. Immutable things appear to change but actually create a new mutable thing.

For example here is a map in Clojure

<pre><code>(def imap {1 "1" 2 "2"})
(conj imap [3 "3"])
(println imap)
</code></pre>

The first line creates a new immutable Clojure map. The second line conjoins 3 and "3" to the map. This may appear as if it is modifying the old map but in reality it is returning a new map with 3 "3" added. This is a prime example of immutability. If this had been a mutable map it would have simply added 3 "3" directly to the same old map. The third line prints the map 

<pre><code>{3 "3", 1 "1", 2 "2"}
</code></pre>

Immutability helps keep code clean and safe. This and other reasons is why functional programming languages tend to lean towards immutability and less statefulness.

blocks|key|438639|text|让事情变得不可变可以避免大量的常见错误。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|438640|例如，一个学生永远不应该让他们的学生#在他们身上改变。如果您没有提供一种方法来设置变量(并将其设置为const、final或您的语言支持的任何方式)，那么您可以在编译时强制执行。|438641|如果东西是可变的，并且你不希望它们在你传递它们时改变，你需要制作一个你传递的防御性副本。然后，如果您调用的方法/函数更改了项目的副本，则原始副本保持不变。|438642|让东西不可变意味着你不需要记住(或者花时间/记忆)来做防御性的拷贝。|438643|如果你真的在做这个工作，并考虑你做的每个变量，你会发现绝大多数(我通常有90-95%25)的变量一旦被赋予一个值就永远不会改变。这样做可以使程序更容易遵循，并减少错误的数量。|438644|为了回答您关于状态的问题，状态是“对象”(可以是类或结构)的变量所具有的值。如果你拿一个人来说，“物体”状态是指眼睛颜色、头发颜色、头发长度等。其中一些(比如眼睛的颜色)是不变的，而其他的，比如头发长度是会变的。|438645|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

Making things immutable prevents a large number of common mistakes. 

For example, a Student should never have their student # change on them. If you don't provide a way to set the variable (and make it const, or final, or whatever your language supports) then you can enforce that at compile time.

If things are mutable and you don't want them to change when you pass them around you need to make a defencive copy that you pass. Then if the method/function you call changes the copy of the item the original is untouched. 

Making things immutable means you do not have to remember (or take the time/memory) to make defencive copies.

If you really work at it, and think about each variable you make, you will find that the vast majority (I typically have 90-95%) of your variables never change once they are given a value. Doing this makes programs easier to follow and reduces the number of bugs.

To answer your question on state, state is the values that variables of an "object" (be that a class or a struct) have. If you took a person "object" state would be things like eye colour, hair colour, hair length, etc... some of those (say eye colour) do not change while others, such as hair length do change.

blocks|key|1086248|text|问得好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1086249|多线程。如果所有类型都是不可变的，那么竞争条件就不存在，您可以安全地在代码中抛出任意多个线程。|1086250|显然，如果没有可变性，你就不能完成那么多工作，从而节省了复杂的计算，所以你通常需要一些可变性来创建功能性业务软件。然而，值得注意的是，不变性应该存在于何处，例如任何事务性。|1086251|查找函数式编程和纯洁性的概念，以获得更多关于哲学的信息。您在调用堆栈上存储的(传递给方法的参数)越多，而不是通过引用(如集合或静态可用对象)使它们可用，您的程序就越纯粹，就越不容易出现竞争条件。如今，随着多核的增多，这个话题变得更加重要。|1086252|此外，不可变性减少了程序中的可能性，从而减少了潜在的复杂性和潜在的bug。|1086253|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

Good question.

Multi-threading. If all types are immutable then race conditions don't exist and you're safe to throw as many threads at the code as you wish.

Obviously you can't accomplish that much without mutability save complex calculations so you usually need some mutability to create functional business software. However it is worth recognising where immutability should lie such as anything transactional.

Look up functional programming and the concept of purity for more information on the philosophy. The more you store on the call stack (the params you're passing to methods) as opposed to making them available via references such as collections or statically available objects the more pure your program is and the less prone to race conditions you will be. With more multi-cores these days this topic is more important.

Also immutability reduces the amount of possibilities in the program which reduces potential complexity and potential for bugs.

blocks|key|3658359|text|让我再补充一件事。除了上面提到的所有这些之外，您还需要以下方面的不变性：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3658360|3658361|value+objects+(有时也称为数据对象或pojo)|unordered-list-item|3658362|structs+(在C#/.NET中)-请参见pojo|3658363|3658364|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|L|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|M|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|N|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|P|8|@]|9|@]|A|$]]]|J|$]]

Let me add one more thing. Besides all that was mentioned above you also want immutability for:

<ul>
<li>value objects (sometimes also known as data objects or pojo)</li>
<li>structs (in C#/.NET) - see <a href="https://stackoverflow.com/questions/620692/620725#620725">stackoverflow question about boxing</a></li>
</ul>

blocks|key|438777|text|什么是不变性？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|438778|动物类的不可变性主要应用于对象(字符串、数组、自定义的动物class)|438779|Typically，)如果存在类的不可变版本，也可以使用可变版本。例如，Objective-C和Cocoa同时定义了一个NSString类(不可变的)和一个NSMutableString类。|unordered-list-item|438780|
|438781|如果一个对象是不可变的，那么它在创建之后就不能被更改(基本上是只读的)。你可以把它看作“只有构造函数才能改变对象”。|438782|438783|这与用户输入没有任何直接关系；即使是您的代码也不能更改不可变对象的值。但是，您始终可以创建一个新的不可变对象来替换它。这里是一个伪代码示例；请注意，在许多语言中，您可以简单地使用myString+=+"hello";，而不是像我下面那样使用构造函数，但为了清楚起见，我将其包含在内：|offset|length|style|CODE|438784|String+myString+=+new+ImmutableString("hello");
myString.appendString("+world");+//+Can't+do+this
myString.setValue("hello+world");+//+Can't+do+this
myString+=+new+ImmutableString("hello+world");+//+OK|code-block|syntax|javascript|438785|你提到“一个只返回信息的对象”；这并不会自动使它成为不变性的一个很好的候选者。不可变对象倾向于总是返回与它们构造时相同的值，所以我倾向于说当前时间不是理想的，因为它经常改变。但是，您可以使用特定的时间戳创建MomentOfTime类，并在将来始终返回该时间戳。|438786|不变性的好处|438787|438788|如果您将一个对象传递给另一个函数/方法，则不必担心该对象在函数返回后是否具有相同的值。例如：|438789|438790|String+myString+=+"HeLLo+WoRLd"；String+lowercasedString+=小写(+myString+)；print+myString%2B“转换为”%2B+lowercasedString；|438791|如果lowercase()的实现在创建小写版本时更改了myString，该怎么办？第三行不会给你想要的结果。当然，一个好的lowercase()函数不会做到这一点，但是如果myString是不可变的，这一点是可以肯定的。因此，不可变对象可以帮助实施良好的面向对象编程更容易创建不可变对象thread-safe|438792|It潜在地简化了类的实现(如果您是编写类的人，这很好)|438793|438794|状态|438795|如果你把一个对象的所有实例变量写在纸上，那就是该对象在给定时刻的状态。程序的状态是它的所有对象在给定时刻的状态。随着时间的推移，状态会迅速变化；程序需要改变状态才能继续运行。|438796|然而，随着时间的推移，不可变对象具有固定的状态。一旦创建，不可变对象的状态就不会改变，尽管整个程序的状态可能会改变。这使得跟踪正在发生的事情变得更容易(并看到上面的其他好处)。|438797|entityMap^0|0|0|0|0|0|0|2H|J|0|0|0|0|0|0|0|0|2|B|1P|B|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1K|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|1L|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|1M|8|@]|9|@]|A|$]]|$1|I|3|J|5|F|7|1N|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|1O|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1P|8|@$N|1Q|O|1R|P|Q]]|9|@]|A|$]]|$1|R|3|S|5|T|7|1S|8|@]|9|@]|A|$U|V]]|$1|W|3|X|5|6|7|1T|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1U|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1V|8|@]|9|@]|A|$]]|$1|11|3|12|5|F|7|1W|8|@]|9|@]|A|$]]|$1|13|3|-4|5|6|7|1X|8|@]|9|@]|A|$]]|$1|14|3|15|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|16|3|17|5|6|7|1Z|8|@$N|20|O|21|P|Q]|$N|22|O|23|P|Q]]|9|@]|A|$]]|$1|18|3|19|5|F|7|24|8|@]|9|@]|A|$]]|$1|1A|3|-4|5|6|7|25|8|@]|9|@]|A|$]]|$1|1B|3|1C|5|6|7|26|8|@]|9|@]|A|$]]|$1|1D|3|1E|5|6|7|27|8|@]|9|@]|A|$]]|$1|1F|3|1G|5|6|7|28|8|@]|9|@]|A|$]]|$1|1H|3|-4|5|6|7|29|8|@]|9|@]|A|$]]]|1I|$]]

<h2>What is Immutability?</h2>

<ul>
<li>Immutability is applied primarily to objects (strings, arrays, a custom Animal class)</li>
<li>Typically, if there is an immutable version of a class, a mutable version is also available. For instance, Objective-C and Cocoa define both an NSString class (immutable) and an NSMutableString class.</li>
<li>If an object is immutable, it can't be changed after it is created (basically read-only). You could think of it as "only the constructor can change the object".</li>
</ul>

This doesn't directly have anything to do with user input; not even your code can change the value of an immutable object. However, you can always create a new immutable object to replace it. Here's a pseudocode example; note that in many languages you can simply do <code>myString = "hello";</code> instead of using a constructor as I did below, but I included it for clarity:

<pre><code>String myString = new ImmutableString("hello");
myString.appendString(" world"); // Can't do this
myString.setValue("hello world"); // Can't do this
myString = new ImmutableString("hello world"); // OK
</code></pre>

You mention "an object that just returns information"; this doesn't automatically make it a good candidate for immutability. Immutable objects tend to always return the same value that they were constructed with, so I'm inclined to say the current time wouldn't be ideal since that changes often. However, you could have a MomentOfTime class that is created with a specific timestamp and always returns that one timestamp in the future.

<h2>Benefits of Immutabilty</h2>

<ul>
<li>If you pass an object to another function/method, you shouldn't have to worry about whether that object will have the same value after the function returns. For instance:

<pre><code>String myString = "HeLLo WoRLd";
String lowercasedString = lowercase(myString);
print myString + " was converted to " + lowercasedString;
</code></pre>

What if the implementation of <code>lowercase()</code> changed myString as it was creating a lowercase version? The third line wouldn't give you the result you wanted. Of course, a good <code>lowercase()</code> function wouldn't do this, but you're guaranteed this fact if myString is immutable. As such, immutable objects can help enforce good object-oriented programming practices.</li>
<li>It's easier to make an immutable object thread-safe</li>
<li>It potentially simplifies the implementation of the class (nice if you're the one writing the class)</li>
</ul>

<h2>State</h2>

If you were to take all of an object's instance variables and write down their values on paper, that would be the state of that object at that given moment. The state of the program is the state of all its objects at a given moment. State changes rapidly over time; a program needs to change state in order to continue running.

Immutable objects, however, have fixed state over time. Once created, the state of an immutable object doesn't change although the state of the program as a whole might. This makes it easier to keep track of what is happening (and see other benefits above).

blocks|key|3658470|text|不变性|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3658471|简单地说，当内存在初始化后没有被修改时，它是不可变的。|3658472|用命令式语言(如C、Java和C#+)编写的程序可以随意操作内存中的数据。物理内存的一个区域，一旦留在一边，就可以在程序执行期间的任何时间被执行线程全部或部分修改。事实上，命令式语言鼓励这种编程方式。|3658473|以这种方式编写程序对于单线程应用程序来说是非常成功的。然而，随着现代应用程序开发转向单个进程中的多个并发操作线程，引入了一系列潜在的问题和复杂性。|3658474|当只有一个执行线程时，您可以想象这个线程“拥有”内存中的所有数据，因此可以随意操作它。但是，当涉及多个执行线程时，没有隐含的所有权概念。|3658475|相反，这一负担落在程序员身上，他们必须竭尽全力确保内存中的结构对于所有读取器都处于一致的状态。必须谨慎地使用锁定构造，以防止一个线程在数据被另一个线程更新时看到数据。如果没有这种协调，线程将不可避免地消耗仅更新到一半的数据。这种情况的结果是不可预测的，而且往往是灾难性的。此外，让锁定在代码中正确工作是出了名的困难，如果做得不好，可能会削弱性能，或者在最坏的情况下，死锁将无法恢复地停止执行。|3658476|使用不可变的数据结构可以减少在代码中引入复杂锁定的需要。当保证一段内存在程序的生命周期内不会改变时，多个读取器可以同时访问该内存。他们不可能观察到处于不一致状态的特定数据。|3658477|许多函数式编程语言，如Lisp、Haskell、Erlang、F#和Clojure，本质上都支持不可变的数据结构。正是由于这个原因，随着我们朝着日益复杂的多线程应用程序开发和多计算机计算机体系结构发展，它们重新引起了人们的兴趣。|3658478|状态|3658479|应用程序的状态可以简单地看作是给定时间点的所有内存和CPU寄存器的内容。|3658480|从逻辑上讲，程序的状态可以分为两种：|3658481|3658482|ordered-list-item|3658483|每个正在执行的线程的堆栈状态|3658484|3658485|在托管环境中，例如C#和Java，一个线程不能访问另一个线程的内存。因此，每个线程都“拥有”其堆栈的状态。堆栈可以看作是保存值类型(struct)的局部变量和参数，以及对对象的引用。这些值与外部线程隔离。|offset|length|style|CODE|3658486|但是，堆上的数据可以在所有线程之间共享，因此必须小心控制并发访问。所有引用类型(class)对象实例都存储在堆中。|3658487|在OOP中，类实例的状态是由它的字段决定的。这些字段存储在堆中，因此所有线程都可以访问它们。如果一个类定义了允许在构造函数完成后修改字段的方法，那么这个类是可变的(不是不可变的)。如果字段不能以任何方式更改，则类型是不可变的。需要注意的是，具有所有C#+readonly/Java+final字段的类不一定是不可变的。这些构造确保引用不能更改，但不能更改被引用的对象。例如，字段可能具有对对象列表的不可更改引用，但列表的实际内容可以随时修改。|3658488|通过将类型定义为真正不可变的，它的状态可以被认为是冻结的，因此该类型对于多线程访问是安全的。|3658489|在实践中，将所有类型定义为不可变可能会很不方便。要修改不可变类型上的a值，可能需要进行大量的内存复制。一些语言使这个过程比其他语言更容易，但无论哪种方式，CPU最终都会做一些额外的工作。许多因素决定了复制内存所花费的时间是否超过了锁定争用的影响。|3658490|很多研究已经进入了不可变数据结构的开发中，例如列表和树。当使用这样的结构时，比如一个列表，'add‘操作将返回一个新列表的引用，其中添加了新的项。对上一个列表的引用看不到任何更改，并且仍然具有一致的数据视图。|3658491|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|1U|6|0|14|5|0|3J|8|3X|5|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1M|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1N|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1O|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1P|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1R|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1S|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1T|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|1U|8|@]|9|@]|A|$]]|$1|W|3|-4|5|X|7|1V|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|X|7|1W|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1X|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|1Y|8|@$13|1Z|14|20|15|16]]|9|@]|A|$]]|$1|17|3|18|5|6|7|21|8|@$13|22|14|23|15|16]]|9|@]|A|$]]|$1|19|3|1A|5|6|7|24|8|@$13|25|14|26|15|16]|$13|27|14|28|15|16]]|9|@]|A|$]]|$1|1B|3|1C|5|6|7|29|8|@]|9|@]|A|$]]|$1|1D|3|1E|5|6|7|2A|8|@]|9|@]|A|$]]|$1|1F|3|1G|5|6|7|2B|8|@]|9|@]|A|$]]|$1|1H|3|-4|5|6|7|2C|8|@]|9|@]|A|$]]]|1I|$]]

<h1>Immutability</h1>

Simply put, memory is immutable when it is not modified after being initialised.

Programs written in imperative languages such as C, Java and C# may manipulate in-memory data at will. An area of physical memory, once set aside, may be modified in whole or part by a thread of execution at any time during the program's execution. In fact, imperative languages encourage this way of programming.

Writing programs in this way has been incredibly successful for single-threaded applications. However as modern application development moves towards multiple concurrent threads of operation within a single process, a world of potential problems and complexity is introduced.

When there is only one thread of execution, you can imagine that this single thread 'owns' all of the data in memory, and so therefore can manipulate it at will. However, there is no implicit concept of ownership when multiple executing threads are involved.

Instead, this burden falls upon the programmer who must go to great pains to ensure that in-memory structures are in a consistent state for all readers. Locking constructs must be used in careful measure to prohibit one thread from seeing data while it is being updated by another thread. Without this coordination, a thread would inevitably consume data that was only halfway through being updated. The outcome from such a situation is unpredictable and often catastrophic. Furthermore, making locking work correctly in code is notoriously difficult and when done badly can cripple performance or, in the worst case, case deadlocks that halt execution irrecoverably.

Using immutable data structures alleviates the need to introduce complex locking into code. When a section of memory is guaranteed not to change during the lifetime of a program then multiple readers may access the memory simultaneously. It is not possible for them to observe that particular data in an inconsistent state.

Many functional programming languages, such as Lisp, Haskell, Erlang, F# and Clojure, encourage immutable data structures by their very nature. It is for this reason that they are enjoying a resurgence of interest as we move towards increasingly complex multi-threaded application development and many-computer computer architectures.

<h1>State</h1>

The state of an application can simply be thought of as the contents of all the memory and CPU registers at a given point in time.

Logically, a program's state can be divided into two:

<ol>
<li>The state of the heap</li>
<li>The state of the stack of each executing thread</li>
</ol>

In managed environments such as C# and Java, one thread cannot access the memory of another. Therefore, each thread 'owns' the state of its stack. The stack can be thought of as holding local variables and parameters of value type (<code>struct</code>), and the references to objects. These values are isolated from outside threads.

However, data on the heap is shareable amongst all threads, hence care must be taken to control concurrent access. All reference-type (<code>class</code>) object instances are stored on the heap. 

In OOP, the state of an instance of a class is determined by its fields. These fields are stored on the heap and so are accessible from all threads. If a class defines methods that allow fields to be modified after the constructor completes, then the class is mutable (not immutable). If the fields cannot be changed in any way, then the type is immutable. It is important to note that a class with all C# <code>readonly</code>/Java <code>final</code> fields is not necessarily immutable. These constructs ensure the reference cannot change, but not the referenced object. For example, a field may have an unchangeable reference to a list of objects, but the actual content of the list may be modified at any time.

By defining a type as being truly immutable, its state can be considered frozen and therefore the type is safe for access by multiple threads.

In practice, it can be inconvenient to define all of your types as immutable. To modify the a value on an immutable type can involve a fair bit of memory copying. Some languages make this process easier than others, but either way the CPU will end up doing some extra work. Many factors contribute to determine whether the time spent copying memory outweighs the impact of locking contentions.

A lot of research has gone into the development of immutable data structures such as lists and trees. When using such structures, say a list, the 'add' operation will return a reference to a new list with the new item added. References to the previous list do not see any change and still have a consistent view of the data.

blocks|key|4504643|text|“……我为什么要担心呢？”|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4504644|一个实际的例子是字符串的重复连接。例如，在.NET中：|4504645|string+SlowStringAppend(string+[]+files)
{
++++//+Declare+an+string
++++string+result="";

++++for+(int+i=0;i<files.length;i%2B%2B)
++++{
++++++++//+result+is+a+completely+new+string+equal+to+itself+plus+the+content+of+the+new
++++++++//+file
++++++++result+=+result+%2B+File.ReadAllText(files[i]);
++++}

++++return+result;
}++++

string+EfficientStringAppend(string+[]+files)
{
++++//+Stringbuilder+manages+a+internal+data+buffer+that+will+only+be+expanded+when+absolutely+necessary
++++StringBuilder+result=new+SringBuilder();

++++for+(int+i=0;i<files.length;i%2B%2B)
++++{
++++++++//+The+pre-allocated+buffer+(result)+is+appended+to+with+the+new+string+
++++++++//+and+only+expands+when+necessary.++It+doubles+in+size+each+expansion
++++++++//+so+need+for+allocations+become+less+common+as+it+grows+in+size.+
++++++++result.Append(File.ReadAllText(files[i]));
++++}

++++return+result.ToString();
}|code-block|syntax|javascript|4504646|不幸的是，使用第一个(慢)函数方法仍然很常用。对不变性的理解使得使用StringBuilder如此重要的原因变得非常清楚。|4504647|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|O|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

"... why should I worry about it?"

A practical example is repetitive concatenation of strings. In .NET for example:

<pre><code>string SlowStringAppend(string [] files)
{
 // Declare an string
 string result="";

 for (int i=0;i&lt;files.length;i++)
 {
 // result is a completely new string equal to itself plus the content of the new
 // file
 result = result + File.ReadAllText(files[i]);
 }

 return result;
} 

string EfficientStringAppend(string [] files)
{
 // Stringbuilder manages a internal data buffer that will only be expanded when absolutely necessary
 StringBuilder result=new SringBuilder();

 for (int i=0;i&lt;files.length;i++)
 {
 // The pre-allocated buffer (result) is appended to with the new string 
 // and only expands when necessary. It doubles in size each expansion
 // so need for allocations become less common as it grows in size. 
 result.Append(File.ReadAllText(files[i]));
 }

 return result.ToString();
}
</code></pre>

Unfortunately using the first (slow) function approach is still commonly used. An understanding of immutability makes it very clear why using StringBuilder is so important.

blocks|key|3658580|text|您不能更改不可变对象，因此必须替换它...“去改变它”。即先替换后丢弃。“替换”在这个意义上意味着将指针从一个内存位置(旧值)更改到另一个内存位置(新值)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3658581|请注意，在这样做的过程中，我们现在使用了额外的内存。一些用于旧值，一些用于新值。还请注意，有些人会感到困惑，因为他们看代码，例如：|3658582|string+mystring+=+"inital+value";
mystring+=+"new+value";
System.Console.WriteLine(mystring);+//+Outputs+"new+value";|code-block|syntax|javascript|3658583|然后对自己说：“但是我正在改变它，就在那里，黑白分明的！我的字符串输出‘新值’……我记得你说过我不能改变它？！！”|3658584|但实际上在幕后，发生的是这种新内存的分配，即mystring现在指向不同的内存地址和空间。“不可变”在这个意义上并不是指mystring的值，而是指变量mystring用来存储其值的内存。|3658585|在某些语言中，存储旧值的内存必须手动清除，即程序员必须显式地释放它。记住要这么做。在其他语言中，这是该语言的一个自动特性，即.Net中的垃圾收集。|3658586|这真的让re大吃一惊:内存使用是在高度迭代的循环中，特别是在Ashs的post中使用字符串。假设您在一个迭代循环中构建一个HTML页面，您不断地将下一个HTML块追加到最后一个块中，并且为了好玩，您是在一台高容量服务器上这样做的。如果“旧值内存”没有得到适当的清理，这种“新值内存”的持续分配很快就会变得昂贵，并最终致命。|3658587|另一个问题是，有些人认为像垃圾收集(GC)这样的事情会立即发生。但事实并非如此。有各种优化措施，使得垃圾收集被设置为在更多的空闲时间内进行。因此，在内存被标记为已丢弃的时间和垃圾收集器实际释放内存的时间之间可能会有明显的延迟。因此，如果您只是将问题推迟到GC，那么您可能会遇到大量的内存使用高峰。|3658588|如果GC在内存耗尽之前没有机会进行操作，那么事情就不一定会像其他没有自动垃圾回收的语言那样崩溃。取而代之的是，GC将作为最高优先级的进程来释放被丢弃的内存，无论时间有多糟糕，并且在它清理东西的过程中成为一个阻塞进程。显然，这并不酷。|3658589|因此，基本上，您需要在编写代码时牢记这些事情，并查看您正在使用的语言的文档，以获得最佳实践/模式，以避免/减轻这种风险。|3658590|在Ashs的帖子中，在.Net和字符串中，当涉及到需要不断更改字符串值时，推荐的做法是使用可变的StringBuilder类，而不是不可变的string类。|3658591|其他语言/类型也同样有自己的变通方法。|3658592|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|13|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|14|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|15|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|16|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|17|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|18|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|19|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1A|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1B|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1C|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1D|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]]|11|$]]

You cannot change an immutable object, therefore you must replace it.... "to change it". i.e. replace then discard. "Replacing" in this sense means changing the pointer from one memory location (of the old value) to another (for the new value). 

Note that in doing so we now using additional memory. Some for the old value, some for the new value. Also note, some people get confused because they look at code, such as:

<pre><code>string mystring = "inital value";
mystring = "new value";
System.Console.WriteLine(mystring); // Outputs "new value";
</code></pre>

and think to themselves, "but I am changing it, look right there, in black and white! mystring outputs 'new value'...... I thought you said i couldn't change it?!!" 

But actually under the hood, whats happening is this allocation of new memory i.e. mystring is now pointing at a different memory address and space. "Immutable" in this sense, is not referring to the value of mystring but rather the memory used by the variable mystring to store its value.

In certain languages the memory storing the old value must be manually cleaned up i.e. the programmer must explicitly release it..... and remember to do so. In other languages this is an automatic feature of the language i.e. garbage collection in .Net.

One of the places this really blows out re:memory usage is in highly iterative loops, specially with strings as in Ashs' post. Say you were building an HTML page in an iterative loop, where you constantly appended the next HTML block to the last and, just for kicks, you were doing this on a high volume server. This constant allocation of "new value memory" can quickly get expensive, and ultimately fatal, if the "old value memory", is not properly cleaned up.

Another problem is that some people assume things like garbage collection (GC) happens immediately. But it doesn't. There are various optimizations that occur such that garbage collection is set to occur during the more idle periods. So there can be a significant delay between when the memory is marked as discarded and when it is actually freed by the garbage collector.... so you can suffer large memory usage spikes if you simply defer the problem to the GC. 

If the GC doesn't get a chance to operate before you run out of memory, then things wont necessarily fall over like in other languages that don't have automatic garbage collection. Instead the GC will kick in as the highest priority process to free up the discarded memory, no matter how bad the timing, and become a blocking process while it cleans things up. Obviously, this isn't cool.

So basically, you need to code with these things in mind and look into the documentation for the languages you are using for the best practices/patterns that allow you to avoid/mitigate this risk. 

As in Ashs' post, in .Net and with strings, the recommended practice is to use the mutable StringBuilder class, rather than the immutable string classes when it comes to the need to constantly change a strings value.

Other languages/types will similarly have their own workarounds.

blocks|key|3658631|text|WPF+API中提供了不可变对象提供的潜在性能优势的一个示例。许多WPF类型的公共基类是Freezable。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3658632|几个WPF示例表明，冻结对象(使它们在运行时不可变)可以显着提高应用程序性能，因为不需要锁定和复制。|3658633|就我个人而言，我希望不变性的概念在我最常用的语言C#中更容易表达。有一个可用于字段的readonly修饰符。我也希望在类型上看到一个readonly修饰符，它只允许只读字段为只读类型的类型。从本质上说，这意味着所有状态都需要在构造时注入，并且整个对象图都将被冻结。我想，如果这个元数据是CLR固有的，那么它可以很容易地用于优化GC的垃圾分析。|3658634|entityMap^0|18|9|0|0|16|8|1U|8|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|P|8|@$9|Q|A|R|B|C]|$9|S|A|T|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|U|8|@]|D|@]|E|$]]]|K|$]]

An example of the potential performance benefits offered by immutable objects is available in the WPF API. A common base class of many WPF types is <code>Freezable</code>.

Several WPF examples suggest that freezing objects (making them immutable at runtime) can improve application performance significantly as locking and copying is not required.

Personally I wish the concept of immutability was easier to express in the language I use most often, C#. There is a <code>readonly</code> modifier available for fields. I would like to see a <code>readonly</code> modifier on types as well that would only be allowed for types that only have readonly fields that are of readonly types. Essentially this means that all state would need to be injected at construction time, and that and entire object graph would be frozen. I imagine that were this metadata intrinsic to the CLR then it could be easily used to optimise garbage analysis for GC.

blocks|key|439076|text|对不起，为什么不可变性会阻止竞争条件(在本例中，读后写风险)？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|439077|shared+v+=+Integer(3)
v+=+Integer(v.value()+%2B+1)+#+in+parallel|code-block|syntax|javascript|439078|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

Sorry, why does immutability prevent race conditions (in this example, write after read hazards)?

<pre><code>shared v = Integer(3)
v = Integer(v.value() + 1) # in parallel
</code></pre>

blocks|key|439137|text|为什么是不变的？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|439138|与可变的secure.|439139|Immutable对象相比，classes.|unordered-list-item|439140|
|439141|Immutable对象是线程安全的，因此没有同步issues.|439142|439143|Immutable对象是好的映射键和集合元素，因为一旦created.|439144|439145|Immutability使其更容易编写，这些元素通常不会改变，因此它们更不容易出错，并且更容易设计、实现和使用|439146|。代码的用法和原因(类不变量建立一次后，由于对象之间没有冲突，所以unchanged).|ordered-list-item|439147|Immutability使程序更容易并行化。即使你有exceptions.|439148|References+to不可变的对象，程序的内部状态也是一致的，因为它们不会改变)。(也就是说，在散列中，它提供了快速operations).|439149|+(|439150|439151|439152|439153|有关更详细的答案，请参阅我的博客：|439154|http://javaexplorer03.blogspot.in/2015/07/minimize-mutability.html|offset|length|439155|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|1U|0|0^^$0|@$1|2|3|4|5|6|7|1F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1G|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|1H|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|1I|8|@]|9|@]|A|$]]|$1|I|3|J|5|F|7|1J|8|@]|9|@]|A|$]]|$1|K|3|H|5|6|7|1K|8|@]|9|@]|A|$]]|$1|L|3|M|5|F|7|1L|8|@]|9|@]|A|$]]|$1|N|3|H|5|6|7|1M|8|@]|9|@]|A|$]]|$1|O|3|P|5|F|7|1N|8|@]|9|@]|A|$]]|$1|Q|3|R|5|S|7|1O|8|@]|9|@]|A|$]]|$1|T|3|U|5|S|7|1P|8|@]|9|@]|A|$]]|$1|V|3|W|5|S|7|1Q|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1R|8|@]|9|@]|A|$]]|$1|Z|3|H|5|6|7|1S|8|@]|9|@]|A|$]]|$1|10|3|-4|5|F|7|1T|8|@]|9|@]|A|$]]|$1|11|3|-4|5|6|7|1U|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|1V|8|@]|9|@]|A|$]]|$1|14|3|15|5|6|7|1W|8|@]|9|@$16|1X|17|1Y|1|1Z]]|A|$]]|$1|18|3|-4|5|6|7|20|8|@]|9|@]|A|$]]]|19|$1A|$5|1B|1C|1D|A|$1E|15]]]]

Why Immutability?

<ol>
<li>They are less prone to error and are more secure.</li>
<li>Immutable classes are easier to design, implement, and use than mutable classes.</li>
<li>Immutable objects are thread-safe so there is no synchronization issues.</li>
<li>Immutable objects are good Map keys and Set elements, since these typically do not change once created.</li>
<li>Immutability makes it easier to write, use and reason about the code (class invariant is established once and then unchanged).</li>
<li>Immutability makes it easier to parallelize program as there are no conflicts among objects.</li>
<li>The internal state of program will be consistent even if you have exceptions.</li>
<li>References to immutable objects can be cached as they are not going to change.(i.e in Hashing it provide fast operations).</li>
</ol>

See my blog for a more detailed answer: 
<a href="http://javaexplorer03.blogspot.in/2015/07/minimize-mutability.html" rel="nofollow noreferrer">http://javaexplorer03.blogspot.in/2015/07/minimize-mutability.html</a>

blocks|key|4504944|text|不变性是关于价值的，而价值是关于事实的。如果某些东西是不可改变的，那么它就有价值，因为如果某些东西可以改变，那么就意味着没有特定的值可以连接到它。对象是用状态A初始化的，在程序执行过程中变成了状态B和状态C。这意味着对象不代表单个特定值，而只是一个容器，在内存中的某个位置上的抽象，仅此而已。你不能信任这样的容器，你不能相信这个容器有你认为应该有的值。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4504945|让我们转到示例-让我们想象一下，在代码中创建了Book类的实例。|4504946|Book+bookPotter+=++new+Book();
bookPotter.setAuthor('J.K+Rowling');
bookPotter.setTitle('Harry+Potter');|code-block|syntax|javascript|4504947|这个实例设置了一些字段，比如author和title。一切都很好，但是在代码的某些部分再次使用了setter。|4504948|Book+bookLor+=++bookPotter;+//+only+reference+pass
bookLor.setAuthor('J.R.R+Tolkien');
bookLor.setTitle('Lords+of+The+Rings');|4504949|不要被不同的变量名欺骗，实际上它是同一个实例。代码再次在同一实例上使用setter。这意味着bookPotter从来不是真正的哈利波特书，bookPotter只是指向未知书籍所在位置的唯一指针。也就是说，它看起来更像是书架而不是书。你对这样的对象有什么信任？它是哈利波特的书还是LoR的书，或者都不是？|4504950|类的可变实例只是指向具有类特征的未知状态的指针。|offset|length|style|BOLD|4504951|那么如何避免突变呢？这在规则中非常简单：|4504952|4504953|通过构造函数或生成器构造具有所需状态的对象|unordered-list-item|4504954|不为对象的封装状态创建setter|4504955|不在其任何方法中更改对象的任何封装状态|4504956|4504957|这几条规则将允许拥有更可预测和更可靠的对象。回到我们的例子，遵循上面的规则：|4504958|Book+bookPotter+=++new+Book('J.K+Rowling',+'Harry+Potter');
Book+bookLor+=+new+Book('J.R.R+Tolkien',+'Lord+of+The+Rings');|4504959|一切都是在构建阶段设置的，在本例中是构造器，但对于更大的结构，它可以是构建器。对象中不存在setter，book不能变异为不同的setter。在这种情况下，bookPotter代表了哈利波特书的价值，你可以肯定这是不可改变的事实。|4504960|如果您对更广泛的不变性感兴趣，在这篇medium文章中将更多地介绍与JavaScript+-+https://medium.com/@macsikora/the-state-of-immutability-169d2cd11310相关的主题。|4504961|entityMap|0|LINK|mutability|MUTABLE|url|https://medium.com/@macsikora/the-state-of-immutability-169d2cd11310^0|0|0|0|0|0|0|2|M|0|0|0|0|0|0|0|0|0|0|1B|1W|0|0^^$0|@$1|2|3|4|5|6|7|1L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1M|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|1N|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|1O|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|1P|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1R|8|@$Q|1S|R|1T|S|T]]|9|@]|A|$]]|$1|U|3|V|5|6|7|1U|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1V|8|@]|9|@]|A|$]]|$1|X|3|Y|5|Z|7|1W|8|@]|9|@]|A|$]]|$1|10|3|11|5|Z|7|1X|8|@]|9|@]|A|$]]|$1|12|3|13|5|Z|7|1Y|8|@]|9|@]|A|$]]|$1|14|3|-4|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|15|3|16|5|6|7|20|8|@]|9|@]|A|$]]|$1|17|3|18|5|F|7|21|8|@]|9|@]|A|$G|H]]|$1|19|3|1A|5|6|7|22|8|@]|9|@]|A|$]]|$1|1B|3|1C|5|6|7|23|8|@]|9|@$Q|24|R|25|1|26]]|A|$]]|$1|1D|3|-4|5|6|7|27|8|@]|9|@]|A|$]]]|1E|$1F|$5|1G|1H|1I|A|$1J|1K]]]]

Immutability is about values, and values are about facts. Something has value if is unchangeable, because if something can be changed, then it means that no specific value can be connected to it. Object was initialized with state A and during program execution was mutated to state B and state C. It means that object doesn't represent single specific value but is only a container, abstraction on a place in the memory, nothing more. You can't have trust to such container, you can not believe that this container has the value you suppose should have.

Let's go to example - lets imagine that in code is created instance of Book class. 

<pre><code>Book bookPotter = new Book();
bookPotter.setAuthor('J.K Rowling');
bookPotter.setTitle('Harry Potter');
</code></pre>

This instance has some fields set like author and title. Everything is ok, but in some part of the code again setters are used.

<pre><code>Book bookLor = bookPotter; // only reference pass
bookLor.setAuthor('J.R.R Tolkien');
bookLor.setTitle('Lords of The Rings');
</code></pre>

Don't be cheated by different variable name, really it is the same instance. The code is using setters on the same instance again. It means that bookPotter was never really the Harry Potter book, bookPotter is only pointer to the place where unknown book is located. That said, it looks like it is more a shelf then the book. What trust you can have to such object? It is Harry Potter book or LoR book or neither? 

Mutable instance of a class is only a pointer to an unknown state with the class characteristics.

How then avoid mutation? It is quite easy in rules:

<ul>
<li>construct object with wanted state via constructor or builder</li>
<li>don't create setters for encapsulated state of the object</li>
<li>don't change any encapsulated state of the object in any of its methods</li>
</ul>

These few rules will allow to have more predictable and more reliable objects. Back to our example and book following above rules:

<pre><code>Book bookPotter = new Book('J.K Rowling', 'Harry Potter');
Book bookLor = new Book('J.R.R Tolkien', 'Lord of The Rings');
</code></pre>

Everything is set during constructing phase, in this case constructor, but for bigger structures it can be a builder. No setters exist in objects, book can not mutate to different one. In such case bookPotter represents value of Harry Potter book and you can be sure that this is unchangeable fact.

If you are interested in wider scope of immutability, in this medium article is more about the subject in relation to JavaScript - <a href="https://medium.com/@macsikora/the-state-of-immutability-169d2cd11310" rel="nofollow noreferrer">https://medium.com/@macsikora/the-state-of-immutability-169d2cd11310</a>.

I've read a couple of articles on immutability but still don't follow the concept very well.

I made a thread on here recently which mentioned immutability, but as this is a topic in itself, I am making a dedicated thread now.

I mentioned in the past thread that I thought immutability is the process of making an object read only and giving it low visibility. Another member said it didn't really have anything to do with that. <a href="http://blogs.msdn.com/lucabol/archive/2007/12/03/creating-an-immutable-value-object-in-c-part-i-using-a-class.aspx" rel="noreferrer">This page</a> (part of a <a href="http://blogs.msdn.com/lucabol/archive/2007/12/03/creating-an-immutable-value-object-in-c-part-i-using-a-class.aspx" rel="noreferrer">series</a>) uses an example of an immutable class/struct and it uses readonly and other concepts to lock it down.

What exactly is the definition of state in the case of this example? State is a concept which I haven't really grasped.

From a design guideline perspective, an immutable class must be one which does not accept user input and really would just return values?

My understanding is that any object which just returns information should be immutable and "locked down", right? So if I want to return the current time in a dedicated class with that one method, I should use a reference type as that will work a reference of the type and thus I benefit from immutability.

What is immutability and why should I worry about it?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我已经读了几篇关于不变性的文章，但仍然没有很好地理解这个概念。我最近在这里做了一个提到不变性的帖子，但由于这本身就是一个主题，我现在正在制作一个专门的帖子。我在过去的帖子中提到过，我认为不变性是将对象设为只读并使其具有低可见性的过程。另一位成员表示，这与此没有任何关系。 (的一部分)使用了一个不可变的类/结构的例子，它...

问什么是不变性，我为什么要担心它？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问什么是不变性，我为什么要担心它？EN