This week's book giveaway is in the Android forum.
We're giving away four copies of Head First Android and have Dawn & David Griffiths on-line!
See this thread for details.
The moose likes Beginning Java and the fly likes String and StringBuffer Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Head First Android this week in the Android forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "String and StringBuffer" Watch "String and StringBuffer" New topic

String and StringBuffer

Tulsi Rai
Ranch Hand

Joined: Jun 26, 2002
Posts: 55
Hi All,
could you please tell me a particular situation where StringBuffer is chosen over String? and why? is it always good to use StringBuffer instead of String?

The other thing is that what are the things I should put in interface? I know what interface is from the theoretical perspective. but I would appreciate if any real-world professional would give me his/her design and developmental perspectives on interface and abstract class.
Ben Buchli
Ranch Hand

Joined: Mar 26, 2004
Posts: 83
since String is immutable, you can use StringBuffer whenever you need to modify a String. Otherwise use String. a good example would be when you want to read a file and store it in a StringBuffer, so that you can access/modify the content.

hope that helps,
Mike Gershman
Ranch Hand

Joined: Mar 13, 2004
Posts: 1272
Reasons to use String instead of StringBuffer:

1. Many methods that take a String argument don't accept a StringBuffer argument.

2. The String class has many useful methods and constructors not available from StringBuffer.

3. String is handled very efficiently in terms of memory and execution time by most jvm's.

Of course, objects that change often should be of class StringBuffer because every attempted modification to a String object actually creates a new object and modifies the String reference to point to the new object (less efficient than StringBuffer). If there are no other references to the old String object, it may be garbage collected. If there are other reference to the old String object, they still point to the old object, a source of confusion.

As for comparing abstract classes to interfaces, an abstract class can do everything an interface can do and much more, such as providing a concrete (fully coded) method to its children. However, a Java child class can only inherit from one parent class (and the parent's parent, etc.) but a Java class can implement many interfaces.

The most common use of interfaces is as the type of a method parameter where the method accepts any object that implements specific methods, you don't care how. Think about a sorting method that can handle any set of objects, perhaps of different types, provided the objects all have a compareTo(Object o) method. Just specify that your sorting method accepts objects of type Comparable. The Comparable interface includes the signature of the compareTo(Object o) method, so the Java compiler will enforce your rule. Notice that each object can have a different parent class as long as it implements Comparable.

Another use of interfaces is a marker interface such as Serializable. A marker interface doesn't have any methods. It's just a sort of compiler-readable specification that objects implementing that interface have some capability or characteristic. You can use the interface name as a parameter type or just test for it with the instanceof operator.
[ July 05, 2004: Message edited by: Mike Gershman ]

Mike Gershman
SCJP 1.4, SCWCD in process
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608

As for comparing abstract classes to interfaces, an abstract class can do everything an interface can do and much more, such as providing a concrete (fully coded) method to its children.

Not quite.
Only an interface can be attached to a proxy (java.lang.reflect.Proxy).
Only an interface is guaranteed to have a "pure null" implementation - this can have an effect on design.
Zero or more interfaces can be implemented - only one abstract class can be inherited from.
Interfaces methods are always public (implicitly or not) - Abstract class methods are of any access scope - this affects design.
Interface fields are always public, static and final (implicitly or not) - Abstract class fields aren't - this affects design.

As a general rule:
- Interfaces provide no implementation.
- Abstract classes provide between zero and full implementation inclusive. For an abstract class to provide zero implementation suggests that it be better provided as an interface - For an abstract class to provide full implementation suggests that it be better provided as a concrete class. i.e. An abstract class can provide zero or full implementation but do so suggests a design flaw.
- Concrete classes provide full implementation.

Tony Morris
Java Q&A (FAQ, Trivia)
Mike Gershman
Ranch Hand

Joined: Mar 13, 2004
Posts: 1272
Hi Tony:

I said that abstract classes can do anything that interfaces can do, not the other way around. Most of your counter-examples were restrictions on interfaces vis a vis abstract classes.

It is true that a class can inherit from at most one class but can implement any number of interfaces. IMHO, that's why interfaces exist.

Your point about java.lang.reflect.Proxy is correct and there are probably plenty of library classes that wouldn't work with a class instead of an interface for reasons of grammar or multiple inheritance, but you are talking heavy stuff here. I was just referring to Java grammar, not to library classes.

It is sorta covered in the JavaRanch Style Guide.
subject: String and StringBuffer
It's not a secret anymore!