• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

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

 
Gian Franco
blacksmith
Ranch Hand
Posts: 979
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Herb Schildt
Author
Ranch Hand
Posts: 253
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Gian:

Since I could only offer conjectures, I must remain silent regarding your question. Perhaps someone else has some thoughts?
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[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 ]
 
Herb Schildt
Author
Ranch Hand
Posts: 253
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 15302
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Warren Dew
blacksmith
Ranch Hand
Posts: 1332
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 15302
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1312
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,


Why i should be use StringBuilfer ??

... answer is like Use Vector instead ArrayList or not
 
Pradeep bhatt
Ranch Hand
Posts: 8927
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
somkiat puisungnoen
Ranch Hand
Posts: 1312
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8927
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1312
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm Clear , Thank you very much...
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic