Forums Register Login

Making an object that cannot be changed

+Pie Number of slices to send: Send
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,
+Pie Number of slices to send: Send
Seems like you've done it. It's immutable. You don't have any setter's (good thing).
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
Good catch. So you'd need

You'd have to do something similar in your getBirthDate() method.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
 

A few minutes ago, I wrote:. . . a nice pound of LocalDate . . .

. . . or even a kilogram.
+Pie Number of slices to send: Send
 

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...
;)
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
I thought about hashCode and equals, but Stephan also did...he made them final.
+Pie Number of slices to send: Send
Yep. Campbell, check out lines 26 and 37 of my code.
+Pie Number of slices to send: Send
I hadn't noticed that bit.
+Pie Number of slices to send: Send
I think I am going to have to concede defeat
+Pie Number of slices to send: Send
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.  
It's a tiny ad only because the water is so cold.
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 3425 times.
Similar Threads
== and .equals()
Item 13 Favor Immutability from Effective Java Edition #1
Infamous getAge() method help
Will this class be always safe to use in a multi-threaded environment?
date field in struts
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 06:21:56.