permaculture playing cards*
The moose likes Java in General and the fly likes Q 4 H.Schildt (5): getters/setters instead of new classes. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Q 4 H.Schildt (5): getters/setters instead of new classes." Watch "Q 4 H.Schildt (5): getters/setters instead of new classes." New topic
Author

Q 4 H.Schildt (5): getters/setters instead of new classes.

Gian Franco
blacksmith
Ranch Hand

Joined: Dec 16, 2003
Posts: 977
Dear author,

Java had the classes String and StringBuffer
now there is also StringBuilder.

I might raise some eyebrows here, but why does
the design preference go to creating new classes
and not, in some of the cases, to providing new
attributes in an existing class with getters/setters
that the programmer can change when desired, like
setSynchronized(boolean i)?

Or should I go back and read an OO book?

Cheers,

Gian Franco Casula
[ August 25, 2004: Message edited by: Gian Franco Casula ]

"Eppur si muove!"
Herb Schildt
Author
Ranch Hand

Joined: Oct 01, 2003
Posts: 239
Gian:

Since I could only offer conjectures, I must remain silent regarding your question. Perhaps someone else has some thoughts?


For my latest books on Java, including my Java Programming Cookbook, see HerbSchildt.com
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[Herb]: Since I could only offer conjectures, I must remain silent regarding your question.

C'mon, Herb, the rest of us don't let that stop us.

My thinking is that StringBuffer has a clear API in this regard: " The methods are synchronized where necessary so that all the operations on any particular instance behave as if they occur in some serial order that is consistent with the order of the method calls made by each of the individual threads involved.". It doesn't say "unless you call the setSomeAttribute() method which overridces this behavior." To change the behavior at this point would effectively break the contract of the class as it's used now. Hence, Sun supplies a new class instead.

Alternately, it could be that changing the behavior to make the synchronization configurable would result in slower performance than either StringBuffer ir StringBuilder currently has. Which would undermine the whole point of adding the new class.

See also recent descussion here.
[ August 25, 2004: Message edited by: Jim Yingst ]

"I'm not back." - Bill Harding, Twister
Herb Schildt
Author
Ranch Hand

Joined: Oct 01, 2003
Posts: 239
Jim:

OK, you win!

Although I don't have personal knowledge of the decision making involved, here is my guess.

Actually, my guess is that you are right -- on both counts. First, I would guess that they would not want to break (or at least alter) the contract defined by StringBuffer. Second, adding selectable synchronization may be either inefficient, difficult, or both. Furthermore, altering existing, well used, debugged code is risky. Why do it if you don't have to? Adding a new class is a clean solution.
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Adding a new class is a clean solution.

This would get my vote.

Worse case scenerio they create a StringBuilder class that extends StringBuffer if they really wanted StringBuilder to have the functionallity of StringBuffer. But I don't see how that would have been the cleanest solution.

Adding functionallity to an existing class is fine and dandy but there comes a time when a class can get bloated with too much all-in-one-ness.


GenRocket - Experts at Building Test Data
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
This seems to me entirely cognate to the switchover from Vector to ArrayList, which I thought was handled well.
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Originally posted by Warren Dew:
This seems to me entirely cognate to the switchover from Vector to ArrayList, which I thought was handled well.


Now if they could only make it so that the Swing API uses ArrayList instead of Vectors in the Models.
somkiat puisungnoen
Ranch Hand

Joined: Jul 04, 2003
Posts: 1312
Hi all,


Why i should be use StringBuilfer ??

... answer is like Use Vector instead ArrayList or not


SCJA,SCJP,SCWCD,SCBCD,SCEA I
Java Developer, Thailand
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Originally posted by somkiat puisungnoen:
Hi all,


Why i should be use StringBuilfer ??

... answer is like Use Vector instead ArrayList or not

somkiat ,

StringBuilder does not use synchorination, so use it when you dont need synchornization. Most of time you dont need it.


Groovy
somkiat puisungnoen
Ranch Hand

Joined: Jul 04, 2003
Posts: 1312
Originally posted by Pradeep Bhat:

somkiat ,

StringBuilder does not use synchorination, so use it when you dont need synchornization. Most of time you dont need it.



So, i should be use StringBuffer when i'm send data in IO, across network.

And in normal program , i should be use StringBuilder instead StringBuffer. All Right ??
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

So, i should be use StringBuffer when i'm send data in IO, across network.


StringBuilder is serializable, so you can pass it across the network.So is StringBuffer.

somkiat puisungnoen
Ranch Hand

Joined: Jul 04, 2003
Posts: 1312
I'm Clear , Thank you very much...
 
jQuery in Action, 2nd edition
 
subject: Q 4 H.Schildt (5): getters/setters instead of new classes.