Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Agile forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

imutable class

 
Duray Rajesh
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi
Hw can i make a user defined class immutable
 
Chengwei Lee
Ranch Hand
Posts: 884
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Make it a final class. Check out the Java API for examples, such as the String class.
 
Duray Rajesh
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi,
I have another doubt, Stringbuffer also declared as final,but we
are calling it as Mutable one,how?
 
Jesper de Jong
Java Cowboy
Saloon Keeper
Posts: 15207
36
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just making the class final is not enough to make it immutable.

Immutable means that the state of instances of the class can't be changed after the instance is initialized. There are a number of reasons that explain why you would want that, I'm not going to explain them here.

Class java.lang.String for example is immutable - the class does not contain any methods that change the content of the string (although new users sometimes are confused about this).

To make an immutable class, you simply have to make sure that you don't provide any methods in the class that alter the state of the object after initialization.
 
Rajah Nagur
Ranch Hand
Posts: 239
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jesper Young:

To make an immutable class, you simply have to make sure that you don't provide any methods in the class that alter the state of the object after initialization.


But cannot a class state be altered by using Reflection API?
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24208
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Rajah Nagur:


But cannot a class state be altered by using Reflection API?


Yes, but this doesn't count. Reflection can be blocked by a SecurityManager, so if you need to be able to really trust that an immutable class is immutable (as when a container is hosting downloaded code, like an applet container) then the SecurityManager can enforce this.
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You create a type contract (read: interface) that declares that all operations are referentially transparent (hint: google search term). Since referential transparency generally applies to functional programming (FP), I will show you a simplified version of the translation from OO to FP.

Any OO "method" has a direct analogous function. Simply, take the type that it is declared on and add that type as the first parameter to a function.

Here is a quick (because I've said it enough times already) example:
Given String.charAt(int), the translation to a function is (very roughly):
char charAt(String, int).
This function is referentially transparent. In fact, all operations on type String can be said to be referentially transparent, therefore, we (well you might but I don't) say it is immutable. I don't use this term because of its association with informality, marketing literature and established but ill-formed beliefs.

Perhaps it's time for a detailed FAQ.
 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Tony Morris:
Perhaps it's time for a detailed FAQ.


Indeed. That was a very good explanation if a little thin for brevity.
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Tony Morris:
You create a type contract (read: interface) that declares that all operations are referentially transparent (hint: google search term). Since referential transparency generally applies to functional programming (FP), I will show you a simplified version of the translation from OO to FP.

Any OO "method" has a direct analogous function. Simply, take the type that it is declared on and add that type as the first parameter to a function.

Here is a quick (because I've said it enough times already) example:
Given String.charAt(int), the translation to a function is (very roughly):
char charAt(String, int).
This function is referentially transparent. In fact, all operations on type String can be said to be referentially transparent, therefore, we (well you might but I don't) say it is immutable. I don't use this term because of its association with informality, marketing literature and established but ill-formed beliefs.

Perhaps it's time for a detailed FAQ.


Upon rereading this, I feel compelled to add one more point, since it is very important. Going back to the statement that the function:
char charAt(String, int) is referentially transparent, we (as users of Java) know this because the API "says so". We cannot write a "unit test" for it. Here is roughly how it would look like if you attempted it:

Obviously you cannot iterate to infinity. In fact, in Java is impossible to prove referential transparency. I believe that if this were not the case, the way we approach software development with Java would be extremely different.

In contrast, functional programming languages provide mathematical proof of referential transparency. Or simply, "if it ain't referentially transparent, it won't compile".
 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would be curious how FP mathematically proves it in a way Java cannot but that's a bit off-topic.
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24208
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Tony Morris:
in Java is impossible to prove referential transparency.


Sorry, Tony, but that's just prejudicial twaddle.



Axioms, from the JLS:

i) a private member is accessible only by code within its class
ii) only assignment can change the value of a variable
iii) a class's code doesn't change over time

Proof:

1) By inspection, there are no assignments to x in this class
2) By (i), there can be no assignments to x from any other class
3) By 1, 2, (ii), and (iii), x will never change; it is a constant
4) x() returns a constant; it is referentially transparent (by definition).

The only hole in this proof is reflection, and if you invoke that to beat down this, than I can invoke any sort of extra-lingual memory-address-twiddling to make any Scheme function return a random number, too.

I assert that similar proofs can be constructed for any class that we would call "immutable."
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Sorry, Tony, but that's just prejudicial twaddle.

It's not actually - though I'm not compelled to prove my case given the lack of depth in the initial refutation. I have work to do...
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
On second though, I retract and resort to my initial comment of the requirement of a "detailed FAQ".
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic