Immutable object: Difference between revisions

Revision as of 14:51, 3 December 2020

Revision as of 13:28, 7 January 2021

Line 23:

| work = Java Ranch

| quote = The preferred way is to make the class final. This is sometimes referred to as "Strong Immutability". It prevents anyone from extending your class and accidentally or deliberately making it mutable.

| accessdateaccess-date = 2012-05-14

}}</ref> This might, for example, help to explicitly enforce certain invariants about certain data in the object staying the same through the lifetime of the object. In some languages, this is done with a keyword (e.g. <code>const</code> in [[C++]], <code>final</code> in [[Java (programming language)|Java]]) that designates the field as immutable. Some languages reverse it: in [[OCaml]], fields of an object or record are by default immutable, and must be explicitly marked with <code>mutable</code> to be so.

Line 192:

Now the String <code>s</code> references a new String object that contains "abc". There is nothing in the syntax of the ''declaration'' of the class String that enforces it as immutable; rather, none of the String class's methods ever affect the data that a String object contains, thus making it immutable.

The keyword <code>final</code> ([[Final (Java)#Final variables|detailed article]]) is used in implementing immutable primitive types and object references,<ref>{{cite web|url=http://javarevisited.blogspot.co.uk/2013/03/how-to-create-immutable-class-object-java-example-tutorial.html |title=How to create Immutable Class and Object in Java – Tutorial Example |publisher=Javarevisited.blogspot.co.uk |date=2013-03-04 |accessdateaccess-date=2014-04-14}}</ref> but it cannot, by itself, make ''the objects themselves'' immutable. See below examples:

Primitive type variables (<code>int</code>, <code>long</code>, <code>short</code>, etc.) can be reassigned after being defined. This can be prevented by using <code>final</code>.

Line 210:

m = new MyObject(); // does not compile. m is final so can't be reassigned </syntaxhighlight>

Primitive wrappers (<code>Integer</code>, <code>Long</code>, <code>Short</code>, <code>Double</code>, <code>Float</code>, <code>Character</code>, <code>Byte</code>, <code>Boolean</code>) are also all immutable. Immutable classes can be implemented by following a few simple guidelines.<ref>{{cite web | url=http://www.javapractices.com/topic/TopicAction.do?Id=29 | title=Immutable objects | publisher=javapractices.com | accessdateaccess-date=November 15, 2012}}</ref>

=== Perl ===

Line 441:

defines an immutable entity <code>maxValue</code> (the integer type is inferred at compile-time) and a mutable entity named <code>currentValue</code>.

By default, collection classes such as <code>List</code> and <code>Map</code> are immutable, so update-methods return a new instance rather than mutating an existing one. While this may sound inefficient, the implementation of these classes and their guarantees of immutability mean that the new instance can re-use existing nodes, which, especially in the case of creating copies, is very efficient.<ref>{{cite web|url=http://www.scala-lang.org/docu/files/collections-api/collections_12.html |title=Scala 2.8 Collections API – Concrete Immutable Collection Classes |publisher=Scala-lang.org |accessdateaccess-date=2014-04-14}}</ref>{{Better source|reason=This is a controversial (and vague) claim, so should be supported by a source other than the Scala foundation itself.|date=July 2017}}

== See also ==