String and StringBuffer

[Tulsi Rai]

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.
thanks.

[Ben Buchli]

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,
Ben

[Mike Gershman]

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 ]

[Tony Morris]

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.

[Mike Gershman]

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.

Mike