Re: Abstract Class versus an Interface, when no Members in Common
On 11/04/2011 12:09 AM, KevinSimonson wrote:
I have a method that needs to be able to return either of two very
different types of data,
Based on what criteria?
in one case a class consisting of a two-
dimensional array of<int>s accompanied by a single<byte> value, and
in the other case just a one-dimensional array of<int>s and that's
all. So I created an abstract class called<SearchResult> that has no
members, not even any constructors, and made two classes extend
<SearchResult>, the one class having the two-dimensional array and the
<byte> value, and the other having the one-dimensional array. Then I
have my method return a value of<SearchResult>.
My question is, in a situation like this where there are absolutely no
variables or methods the two classes have in common, is it better to
have an abstract class that both classes extend, or is it better to
have an interface that both classes implement? Or is there any
difference between the two approaches?
Since your result classes do not have anything in common you could as
well use Object as return type. From your description the caller needs
to downcast SearchResult anyway. If SearchResult does not have any
properties (methods) then the type may be superfluous altogether. There
are really only few cases where an interface without methods does make
sense (e.g. Serializable and Cloneable as tagging interfaces). In your
case the only property that could be associated with the empty interface
(or abstract class) SearchResult is that it is returned by your method
X. But that is not a property of a type; rather it is an indication of
usage.
If it's clear at call site which return type you'll get you could have a
method with a generic type parameter, e.g.
public <T> T search(...) {...}
Maybe you even have two search methods with different argument lists
each returning a specific type.
Kind regards
robert