• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

how can we make class "immuatble" explicitly

 
Ganesh Gowtham
Ranch Hand
Posts: 225
IBM DB2 Eclipse IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Friends...
i just want to get clarify my doubts about "immutable class"
String class in JDK is immutable , i think even some wrapper classes like Boolean Integer is also i am not
sure about that.

How to make a my own class immutable and what is advantage that i get while coding a class as "immutable".
some i when googled i came to know we have to in corporate all thses in class to make a class "immutable"
class sud be final , with private fields and it sud not have seeter methods.

then is the immutable class then, ??
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24212
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That is an immutable class, but of course not a very useful class!

"Immutable" just means "not changeable." An object of an immutable class represents a constant of some kind, simple or complex; once initialized, it doesn't change what it represents. That's all.

In any case, I think your checklist is reasonable, although I'd generalize "no setters" to "no code that changes the user-visible state."
 
Ganesh Gowtham
Ranch Hand
Posts: 225
IBM DB2 Eclipse IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I just posted this because String is the "immutable" and creates a new object when ever the data is added ...

like


Now as end of the line 2 str is "intial text" now str in line 2 is pointing to newly created test and str
in the line 1 which is pointed to "intial" is garbage collected .... and same applies to line 3....,

Since This "immutable" class is all disadvantge they SUN tried to remove it or rather re define those classes muthable one...

Since Sun kept i might think there is sort of advantage either in performance or.....

Am i going wrong... any where
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24212
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The StringBuffer and StringBuilder classes are provided to efficiently assemble Strings from pieces. If Strings weren't immutable, then you could never save a String passed in as an argument into a member variable or collection without copying it first. Think of how many more copies that would represent!
 
Ganesh Gowtham
Ranch Hand
Posts: 225
IBM DB2 Eclipse IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ernest ,

ok . In short what makes "String" "StrngBuffer" "immutable" and "muttable" coding..Pls let me know...
Since i cant able to get U in prev Message
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24212
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As I said, "immutable" in English just means "not changeable". All this means is that the String API doesn't provide any way to change the contents of the String. The StringBuffer class, on the other hand, you can modify all you want. I think you may be overthinking this -- there's nothing more to it than that. An immutable class is one that doesn't provide any way to change the member variables of an object after it's created. A mutable class is one that does.
 
Ganesh Gowtham
Ranch Hand
Posts: 225
IBM DB2 Eclipse IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Friend ....

at last i found the answer Thanks fo spending your valuable time ....

An immutable class (String) is one that doesn't provide any way to change the member variables of an object after it's created. A mutable class (StringBuffer) is one that does.
[ July 24, 2005: Message edited by: Gowtham Ganamukala ]
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The distinction between mutability and immutability is typicaly made to distinguish between types that should be used locally and/or in method parameters/return types. This is usually a "more correct" design (inadvertantly following Design By Contract). i.e. passing/returning mutable types is an implicit violation of requirement (providing excessive contract).

Therefore, if you were to formalise your approach further, you'd find that you would follow other certain rules (to avoid violation of requirement):
- mutability/immutability is specified on the interface (not the concrete type)
- all contracts (public methods) are specified on an interface.
(there are many more, but I'll omit them for brevity - the biggest single controversial one is that non-final classes imply a violation of requirement)

Unfortunately, the core API violates many of these fundamentals, and by using Java, you typically use the core API, but as it evolves, it moves more and more toward them (will someone in Sun wake up?). For example, the String class now has some of its public methods specified on an interface (java.lang.CharSequence), which specifies immutability (by definition of its API specification). In any case, even if the core API were completely rewritten properly, the language itself is tied to some of these flawed concepts.

Acknowledging the numerous flaws assists in making informed decisions.
Hope this helps.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic