Forums Register Login

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

+Pie Number of slices to send: Send
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 ]
+Pie Number of slices to send: Send
Gian:

Since I could only offer conjectures, I must remain silent regarding your question. Perhaps someone else has some thoughts?
+Pie Number of slices to send: Send
[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 ]
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
This seems to me entirely cognate to the switchover from Vector to ArrayList, which I thought was handled well.
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
Hi all,


Why i should be use StringBuilfer ??

... answer is like Use Vector instead ArrayList or not
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
 

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 ??
+Pie Number of slices to send: Send
 

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.

+Pie Number of slices to send: Send
I'm Clear , Thank you very much...
Get me the mayor's office! I need to tell her about this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 946 times.
Similar Threads
Q 4 H.Schildt (4): how far can annotations go?
Q 4 H.Schildt (6): back to the drawing table...
Q 4 H. Schildt (3): features v.s. JVM implementation dependence
Q 4 C. Bauer & G. King (12): object/relational mismatch
Q 4 H. Schildt (1): scope of features
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 29, 2024 08:16:39.