1

Today while I was reading some documentation regarding the BigDecimal class, I've stumbled upon an fundamental property, the BigDecimal class is Immutable.

How could I explain to my grandmother the immutability concept ?

What are the pro and cons of the immutability of a class ?

Can an extended class become mutable ?

Considering that I want to extend the BigDecimal with my class:

`MyBigDecimal extends BigDecimal`

Does the extending violate the basic Object Oriented design principles ?

user207421
  • 305,947
  • 44
  • 307
  • 483
Lucian Enache
  • 2,510
  • 5
  • 34
  • 59

4 Answers4

9

How could I explain to my grandmother the immutability concept ?

Check this question: What is meant by immutable

Or from Effective Java:

An immutable class is a class whose instances cannot be modified. All of the information contained in each instance is provided when it is created and is fixed for the lifetime of the object.

What are the pro and cons of the immutability of a class ?

Pros:

  • it's easier to reason about the state of the object, because there is only one, the state that was built upon initialisation
  • corollary: immutable objects are easier to use in concurrent programming, where state is everything

Cons:

  • when you want to change a property of the object, you need to create a new one = expensive
  • construction can be more complicated (cf builder pattern)

Can an extended class become mutable ?

Yes - which is why immutable class should be made final (or alternatively, make all constructors private and provide factories to create new objects).

BigDecimal is a good example of what should not be done when creating an immutable class (it can be extended which can cause issues as you mentioned in your question).

Community
  • 1
  • 1
assylias
  • 321,522
  • 82
  • 660
  • 783
3

An Immutable class whose instances never change. The state of the object is defined at construction time and never changes after.

To be properly immutable, the class doesn't provide any way (other than reflection) to change its state: no setter method, no method that changes its internal state, no method that allows accessing to a mutable field it holds. It should also be final (as BigDecimal should be), to prevent any other class to extend it and thus make it mutable by adding mutable fields.

The advantages are many:

  • The class is easy to understand
  • Instances are inherently thread-safe
  • Instances can be cached without needing to return copies from the cache
  • Instances can be used as keys in a Map without fear of being changed after

It doesn't violate OO principles: to the contrary, the state is completely encapsulated in the object.

Note: some immutable objects change their state internally (lazy initialization of some fields, for example) without affecting the externally-visible state of the object. If done properly, it doesn't change the thread-safety of immutable objects. If done incorrectly, it can make them non-thread-safe.

JB Nizet
  • 678,734
  • 91
  • 1,224
  • 1,255
  • Check [`String.hashCode`](http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/lang/String.java#1493), it changes the internal state of a string -- in a completely non-thread-safe way at that. – Marko Topolnik Jul 17 '12 at 10:37
  • 1
    Yeah, but it's a nasty advanced trick. And it's definitely thread-safe, since the only way to access the cached value is through the hashCode() method, which recomputes it in a deterministic way if it's equal to 0. And assignments of int variables are atomic operations. – JB Nizet Jul 17 '12 at 10:40
  • @MarkoTopolnik it is thread safe. Worst case is it gets calculated more than once. – assylias Jul 17 '12 at 10:40
  • 1
    @assylias Yes, it is thread-safe from the `hashCode` contract perspective. It's just a fun piece of code. But my major point is that there is no requirement for "no method that changes its internal state". – Marko Topolnik Jul 17 '12 at 10:47
  • @MarkoTopolnik: agreed. I added a note to my answer to make that clearer. – JB Nizet Jul 17 '12 at 10:52
3

The BigDecimal is a value class. It represents a value from the "real world". Let's take the whole numbers for example. A 42 has always the value 42. It's state cannot be changed. If I want to have the 43 it is not the changed value of 42 but the value of 43. This abstract concept of values is transfered in the object oriented world by using immutable classes. If you want to add a number to your existing one it is not changed but a new immutable object containing the result is created.

André Stannek
  • 7,773
  • 31
  • 52
1

immutability of a class means if object is created you can not change its contents.

Consider e.g. 

String str = "Hello"; // you can not change content Hello to any other string

Pros and cons of immutability of a class - Pros. / Cons. of Immutability vs. Mutability

Can an extended class become mutable ?

Yes you can make it.

MyBigDecimal extends BigDecimal

You can do it BigDecimal is not final.

Community
  • 1
  • 1
Nandkumar Tekale
  • 16,024
  • 8
  • 58
  • 85
  • Actually, you can change its contents. String is an example, if I remember correctly (lazy caching of `hashCode`). Just the outside behavior must not change. – Marko Topolnik Jul 17 '12 at 10:32
  • @MarkoTopolnik : exactly...:) – Nandkumar Tekale Jul 17 '12 at 10:34
  • @MarkoTopolnik lazy caching of hashcode is fine as long as it is not visible externally. Another problem with string is that you can mutate it by using the CharSequence constructor. See [this question](http://stackoverflow.com/questions/11146255/how-to-create-mutable-java-lang-string) for an example. – assylias Jul 17 '12 at 10:37
  • @assylias Of course it's fine, would I doubt the immutability of String? :) – Marko Topolnik Jul 17 '12 at 10:38