• Post Reply Bookmark Topic Watch Topic
  • New Topic

Making an object that cannot be changed  RSS feed

 
Mike Tango
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello ALL,

How can I modify the body of the code (this can include the body of the constructor) to protect Person instances against alteration: Once a Person is created, it should not be possible to modify it.



Regards,
 
Carey Brown
Saloon Keeper
Posts: 3315
46
Eclipse IDE Firefox Browser Java MySQL Database VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Seems like you've done it. It's immutable. You don't have any setter's (good thing).
 
Mike Tango
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Carey Brown wrote:Seems like you've done it. It's immutable. You don't have any setter's (good thing).


No the object is not Immutable using a Date.
 
Carey Brown
Saloon Keeper
Posts: 3315
46
Eclipse IDE Firefox Browser Java MySQL Database VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good catch. So you'd need

You'd have to do something similar in your getBirthDate() method.
 
Junilu Lacar
Sheriff
Posts: 11485
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It may seem like overkill but the addition of final to each of the private field declarations will make your intent to have immutable fields clearer. As you and Carey have already noted, if you want to keep your fields immutable, your getter methods should return defensive copies of any fields that are mutable objects rather than the references themselves.
 
Campbell Ritchie
Marshal
Posts: 56536
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Another reason for not Using Date: look in the Java™ Tutorials and see what else is on offer. I think you will go for a nice pound of LocalDate, which is immutable. If you have mutable reference tyes as fields (and remember that arrays are implicitly mutable) always take a defensive copy of any instances passed into your object or returned out of it.

There is another bit missing for immutability: that class isn't declared as final. There's more about immutability in the Java™ Tutorials.
 
Campbell Ritchie
Marshal
Posts: 56536
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A few minutes ago, I wrote:. . . a nice pound of LocalDate . . .
. . . or even a kilogram.
 
Dave Tolls
Ranch Foreman
Posts: 3056
37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:
A few minutes ago, I wrote:. . . a nice pound of LocalDate . . .
. . . or even a kilogram.


Well, it would be more like 450g...
;)
 
Stephan van Hulst
Saloon Keeper
Posts: 7975
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Technically the class still can't guarantee immutability, because its getters can be overridden by a sub-class. Either make the class or its methods final.
 
Campbell Ritchie
Marshal
Posts: 56536
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You should make the class final, otherwise it is possible for a subclass to add a field and restore mutability. Making  class final implicitly makes all its methods behave as final methods.
 
Stephan van Hulst
Saloon Keeper
Posts: 7975
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:You should make the class final, otherwise it is possible for a subclass to add a field and restore mutability.

I don't consider that to break immutability. Sure, the new properties and methods of the class may be mutable, but any code that uses references of the immutable supertype won't notice any difference at all.

I challenge you to implement MutablePerson in such a way that the program's view of immutable is altered in any way.
 
Campbell Ritchie
Marshal
Posts: 56536
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stephan van Hulst wrote:. . . any code that uses references of the immutable supertype won't notice any difference at all. . . .
That might be a reference to the immutable supertype but the runtime type is mutable; you might need a cast to make Billy Bunter go to a different school, but it can be done.
Yes, it is bad design to add fields like that, and it will mess up equals() too, but it can be done.
 
Dave Tolls
Ranch Foreman
Posts: 3056
37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I thought about hashCode and equals, but Stephan also did...he made them final.
 
Stephan van Hulst
Saloon Keeper
Posts: 7975
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yep. Campbell, check out lines 26 and 37 of my code.
 
Campbell Ritchie
Marshal
Posts: 56536
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I hadn't noticed that bit.
 
Campbell Ritchie
Marshal
Posts: 56536
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think I am going to have to concede defeat
 
Junilu Lacar
Sheriff
Posts: 11485
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Immutability is a deceptively simple concept. Many programmers out there, even good ones, can fall victim to any of a number of pitfalls so don't feel too bad, Campbell. 
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!