Custom Immutable Classes

Question

1) Is it the case that only the reference type objects ( example: string ) can be immutable ? If not please give some samples ?

2) From my knowledge, a class is immutable if all information injected into the class is supplied in the constructor or a factory method. Is it the case that all the items used in the class should themselves be immutable in order to create a custom immutable class?

Note: Please do not mark the question as duplicate by pointing some other questions which are not explicitly answer my questions.

I think [this question](http://stackoverflow.com/questions/352471/how-do-i-create-an-immutable-class?rq=1) has a bit more info for you as well. — Benjamin Diele, Aug 04 '14 at 07:14
The nature of value-types like structs is that they are(should be) immutable. Basic value types are immutable anyway(a one is always one and never two). — Tim Schmelter, Aug 04 '14 at 07:15
*Does only the reference type objects ( example: string ) can be immutable?* No, Did you heard of `DateTime` ? — Sriram Sakthivel, Aug 04 '14 at 07:17
Immutable can [mean many different things](http://blogs.msdn.com/b/ericlippert/archive/2007/11/13/immutability-in-c-part-one-kinds-of-immutability.aspx), which sense do you mean? @TimSchmelter Unfortunately not, which is why "avoid mutable value types" [exists as a guideline](http://stackoverflow.com/q/441309/395760). — , Aug 04 '14 at 07:18
@delnan: even if you can make your struct mutable you should not, mutable value types are evil. Value types are copies, if you change one you'll change only this copy. — Tim Schmelter, Aug 04 '14 at 07:20
@TimSchmelter My point exactly. You just edited your phrasing to be less objectionable since I first read your comment ;-) — , Aug 04 '14 at 07:21
@Tim Schmelter - " Value types are copies, if you change one you'll change only this copy". Does it mean all value types are immutable by default ? — Anoob K A, Aug 04 '14 at 07:33
@AnoobAliyar: not really (as mentioned above), you can change the properties of a struct without a problem although a struct should represent an eternal value. So it's good pratice to make them immutable. Further reading: http://stackoverflow.com/a/3753640/284240 — Tim Schmelter, Aug 04 '14 at 07:40
No, value types are still mutable - you can pass along a reference to a value type (for example, boxed in another class or passed by `ref`). You can ensure they are immutable, though, by only using `readonly` fields. They can still be modified through reflection, but that's your fight :D — Luaan, Aug 04 '14 at 07:40
@ Luaan - I do agree the fields need to be readonly , however is it can be mutable data type? — Anoob K A, Aug 04 '14 at 08:06
The definition of immutable does not change strut to class. The implications change but not the definition. — paparazzo, Aug 04 '14 at 14:02

david.pfx · Answer 1 · 2014-08-04T14:30:40.257

No, I think you have misunderstood.

The essence of immutability is that you are dealing with values, that are known only by their value and do not have an identity. For an object to be mutable it must conceptually have an identity that survives when its value is changed.

So value types in .NET are inherently expected to be immutable, because they are values. The number 7, the floating point number 1.3e17 and the date 1/1/1901 are immutable. variables holding these values may be mutable, but the values themselves are not.

Strings are also immutable. The value "abc" is immutable, even though it happens to be held in a reference type. Strings have no identity, and can be copied freely.

Structs in .NET are value types, and are copied on assignment. This is what you would expect, since copying a value does not create a new entity. It's just a copy of the same value.

The .NET framework does not enforce immutability for user-defined types. You have to do that yourself. You should consider whether a type you create is identified by its value or whether it has an identity, and design your classes and structs accordingly. It is quite reasonable to use structs for immutable values and classes for mutable identifiable objects, but that is up to you to decide and enforce.

It's important to remember the distinction between variables and the values they contain. A String, DateTime or a Point is a value, a StringBuilder or a Stream is not. A String variable contains a String value. A StringBuilder variable contains a reference to a StringBuilder, which in turn contains a String value. A Point variable contains a Point value (which happens to have X and Y int components). The variables are mutable, the values are not.

When a Point is assigned the value does not change but the variable holding it (LHS) changes from old value to new value.

@ david.pfx - Thanks for new information related with identity.I am sorry I got bit confused with the statement immutable do not have an identity but its known by values and I am expecting few more clarification about that.Consider String and StringBuilder both seems known by values , however one is immutable and other one is mutable. How it is differs from identity perspective? — Anoob K A, Aug 04 '14 at 13:36
@ david.pfx - For value types (structs) you are mentioned like copying a value does not create a new entity . It's just a copy of the same value. Are you meant same value or same variable with different value ? Does it will allocated to new stack memory or will use the same stack used by old value? Then how come value types in .NET are inherently expected to be immutable ? — Anoob K A, Aug 04 '14 at 13:36
@ david.pfx - As you said when a Point is assigned the value does not change but the variable holding it (LHS) changes from old value to new value. Does it will result change in memory allocation which is happening for String variable? — Anoob K A, Aug 05 '14 at 08:48
String variable holds a reference, the memory is held elsewhere. This is really going nowhere: you either need to do some reading or ask another question. — david.pfx, Aug 05 '14 at 10:14

Custom Immutable Classes

1 Answers1