Article:		You Are What You Is: Defining Object Identity
Subject:		Immutability through Finalisation?
Date:		2006-08-18 02:04:37
From:		temple_cloud
Response to: i'm really having a hard time...
Yes... immutability is sometimes tricky to understand for me too especially in a non functional language like Java; you really need to know your stuff. I think the example in this interesting article can help highlight this. MY knowledge of java is not that great but I think your example provides a good case for immutability as "best practice" from my current level of understanding. From my knowledge of Java I would "finalise" the state attributes in the objects I am placing into the set; and also remove the "setter" method (that allows the side effect to be produced). So something like this: public class Point { final int x; final int y; public Point (final int x1, final int y1) { x = x1; y = y1; } // Other methods .... } The class is "immutable"; once created it cannot be changed so the issues outlined in the hashSet problem cannot occur. So immutability can often be considered a "best practice". However of course as mentioned in this article solutions depend strongly on the domain of the problem being solved; but if ammeable I believe this is a good solution to the hashset problem (and many others). This is my current thinking and use this pattern (when I can) if I am working with a hashset. I would be interested to know any pitfalls with this if any as I find java can be a very subtle langauge!