• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Knute Snortum
  • Junilu Lacar
  • Devaka Cooray
Saloon Keepers:
  • Ganesh Patekar
  • Tim Moores
  • Carey Brown
  • Stephan van Hulst
  • salvin francis
Bartenders:
  • Ron McLeod
  • Frits Walraven
  • Pete Letkeman

Immutable Objects Creation  RSS feed

 
Ranch Hand
Posts: 362
2
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I understand that Immutable Objects are the ones which can't be changed once instantiated. And, there are few guidelines to follow to make any object as Immutable:

1. Mark the class as final
2. Mark all fields as private and final
3. Don't provide any setters/mutators

What is the need of marking the fields as private and final while the class is already marked as final? Also, if we mark all the fields as private and final and don't mark the class as final then what is the harm in that?
 
Saloon Keeper
Posts: 9371
180
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Guideline 3 is redundant if you follow guideline 2.

Note that these are not enough to make a class immutable. You need to perform defensive copying on mutable components of your class in your constructor, and return unmodifiable views of them (or copies) in assessors.

Methods that are supposed to return the same result every time for a given object need to be final to prevent a subclass from overriding that behavior. The easiest way to do that is to make the class final (which is just good practice to start with). It's not necessary to make the whole class final though, as long as all methods your class contains are final, including those inherited from Object. Any methods added by a subclass that don't behave as if the object is immutable won't violate the contract of the base class. It's highly confusing though, and just making the entire class final is better.

Here's an example:
 
Master Rancher
Posts: 3669
40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

So, someInt is final, and there's no setter, but the class isn't.

Oh dear.  I can now pass round a reference to a SomeClass instance where someInt is not immutable.

For the obverse, where the class is final but the fields are not.

In both cases it's code protection.
If the item in question is not supposed to change then make sure you get an error should someone modify the code and make a mistake.
 
Marshal
Posts: 60704
189
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As Stephan says, inal methods prevent them from being overridden, but an immutable class should be final to prevent subclasses with additional mutable fields from being created.
 
Stephan van Hulst
Saloon Keeper
Posts: 9371
180
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:As Stephan says, inal methods prevent them from being overridden, but an immutable class should be final to prevent subclasses with additional mutable fields from being created.


My point was actually the opposite. You can add additional mutable fields in a subclass, and it won't affect the way the immutable superclass behaves.
 
Campbell Ritchie
Marshal
Posts: 60704
189
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If Bar has any facility to change the value of j, then the superclass might be immutable, but it shows problems with mutable subtypes.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!