This week's book giveaway is in the Testing forum. We're giving away four copies of Data Structures the Fun Way: An Amusing Adventure with Coffee-Filled Examples and have Jeremy Kubica on-line! See this thread for details.
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?
Gian Franco Casula [ August 25, 2004: Message edited by: Gian Franco Casula ]
[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 ]
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.
For my latest books on Java, including Introducing JavaFX 8 Programming, see HerbSchildt.com
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.