Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #9477 > unrolled thread

Abstract Class versus an Interface, when no Members in Common

Back to article view | Back to comp.lang.java.programmer

Contents

  Abstract Class versus an Interface, when no Members in Common KevinSimonson <kvnsmnsn@hotmail.com> - 2011-11-03 16:09 -0700
    Re: Abstract Class versus an Interface, when no Members in Common Arne Vajhøj <arne@vajhoej.dk> - 2011-11-03 19:32 -0400
    Re: Abstract Class versus an Interface, when no Members in Common markspace <-@.> - 2011-11-03 17:37 -0700
      Re: Abstract Class versus an Interface, when no Members in Common Lew <lewbloch@gmail.com> - 2011-11-03 18:10 -0700
        Re: Abstract Class versus an Interface, when no Members in Common markspace <-@.> - 2011-11-03 18:46 -0700
    Re: Abstract Class versus an Interface, when no Members in Common Roedy Green <see_website@mindprod.com.invalid> - 2011-11-03 22:06 -0700
    Re: Abstract Class versus an Interface, when no Members in Common Ian Pilcher <arequipeno@gmail.com> - 2011-11-04 00:06 -0500
    Re: Abstract Class versus an Interface, when no Members in Common Robert Klemme <shortcutter@googlemail.com> - 2011-11-04 17:57 +0100
    Re: Abstract Class versus an Interface, when no Members in Common Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-11-04 13:54 -0700
      Re: Abstract Class versus an Interface, when no Members in Common Wanja Gayk <brixomatic@yahoo.com> - 2011-11-08 23:15 +0100
        Re: Abstract Class versus an Interface, when no Members in Common Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-11-08 20:58 -0800
    Re: Abstract Class versus an Interface, when no Members in Common Roedy Green <see_website@mindprod.com.invalid> - 2011-11-04 15:17 -0700
    Re: Abstract Class versus an Interface, when no Members in Common Wanja Gayk <brixomatic@yahoo.com> - 2011-11-08 23:13 +0100

#9477 — Abstract Class versus an Interface, when no Members in Common

I have a method that needs to be able to return either of two very
different types of data, 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?

Kevin Simonson

[toc] | [next] | [standalone]

#9479

On 11/3/2011 7:09 PM, KevinSimonson wrote:
> I have a method that needs to be able to return either of two very
> different types of data, 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?

I don't like either approach. The calling code would need
to detect what type is actually returned and that would
most likely result in some very ugly code.

Two methods in the public API:

public Typ1 returnFoobarAsTyp1();
public Typ2 returnFoobarAsTyp2();

Arne

[toc] | [prev] | [next] | [standalone]

#9481

On 11/3/2011 4:09 PM, KevinSimonson wrote:
> So I created an abstract class called<SearchResult>  that has no

In the real world, when there's a class like this, there's usually some 
meta data that can decode which type is being returned.  As Arne points 
out, there's usually also a "getAsType" method.  For example, the JDBC 
object has various "getBoolean()" and "getBlob()" methods for accessing 
database columns, as well as metadata describing the object.

While not the best over all (JPA is better, generally, than JDBC), it's 
more structured that just an abstract class with no methods.

I might say that no methods = interface (called a mixin), but I think 
the potential to add common methods here is high.  So, use a base class 
so that you don't get tripped up by Java's single inheritance.  It's the 
most conservative approach in this case.

[toc] | [prev] | [next] | [standalone]

#9489

markspace wrote:
> KevinSimonson wrote:
> > So I created an abstract class called<SearchResult>  that has no
> 
> In the real world, when there's a class like this, there's usually some 
> meta data that can decode which type is being returned.  As Arne points 
> out, there's usually also a "getAsType" method.  For example, the JDBC 
> object has various "getBoolean()" and "getBlob()" methods for accessing 
> database columns, as well as metadata describing the object.
> 
> While not the best over all (JPA is better, generally, than JDBC), it's 
> more structured that just an abstract class with no methods.
> 
> I might say that no methods = interface (called a mixin), but I think 
> the potential to add common methods here is high.  So, use a base class 
> so that you don't get tripped up by Java's single inheritance.  It's the 
> most conservative approach in this case.

The OP's approach seems somewhat hackish, based on the paucity of information provided so maybe it isn't.  Would it work to make the varying type a generic parameter?

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#9495

On 11/3/2011 6:10 PM, Lew wrote:

> The OP's approach seems somewhat hackish, based on the paucity of
> information provided so maybe it isn't.  Would it work to make the
> varying type a generic parameter?


He'd have to add some sort of method(s) to support the generic 
parameter.  Some kind of generic mix-in:

public interface MixMe<T> {}

Seems silly to me, without something specified to be done with T.  Like 
wise a base class with a single generic getter:

public BaseGetter<U> {
   public U get();
}

doesn't seem any different than just making a regular non-generic 
sub-class.  Arne's point of just declaring the methods and return types 
you need in one class seems the most straight forward.

I think he just has to be prepared to refactor a lot of code when the 
right way to do it becomes apparent.  What he's got right now could go 
any way at all.

[toc] | [prev] | [next] | [standalone]

#9504

On Thu, 3 Nov 2011 16:09:08 -0700 (PDT), KevinSimonson
<kvnsmnsn@hotmail.com> wrote, quoted or indirectly quoted someone who
said :

>I have a method that needs to be able to return either of two very
>different types of data, i

Another way to handle it is like this:

  final Calculator calc = new Calculator( a, b,c );
   if ( calc.isStrange() )  
     {  
     final Strange strangeAnswer = calc.getStrangeAnswer();
     ...
     }
   else
    {
    final Ordinary ordinary = calc.getOrdinaryAnswer();
    ...
    }
    
    
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Capitalism has spurred the competition that makes CPUs faster and 
faster each year, but the focus on money makes software manufacturers 
do some peculiar things like deliberately leaving bugs and deficiencies
in the software so they can soak the customers for upgrades later.
Whether software is easy to use, or never loses data, when the company
has a near monopoly, is almost irrelevant to profits, and therefore 
ignored. The manufacturer focuses on cheap gimicks like dancing paper 
clips to dazzle naive first-time buyers. The needs of existing 
experienced users are almost irrelevant. I see software rental as the 
best remedy.

[toc] | [prev] | [next] | [standalone]

#9505

On 11/03/2011 06:09 PM, KevinSimonson wrote:
> I have a method that needs to be able to return either of two very
> different types of data, 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>.

If you *really* need to overload the return value of your method like
this (and I'm skeptical), you can put the 1-dimensional array into a 2-
dimensional array:

  int[] array1D = { 1, 2, 3 };
  int[][] array2D = new int[1][];  // This seems backwards to me
  array2D[0] = array1D;

-- 
========================================================================
Ian Pilcher                                         arequipeno@gmail.com
"If you're going to shift my paradigm ... at least buy me dinner first."
========================================================================

[toc] | [prev] | [next] | [standalone]

#9520

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

[toc] | [prev] | [next] | [standalone]

#9527

On 11/3/11 4:09 PM, KevinSimonson wrote:
> I have a method that needs to be able to return either of two very
> different types of data, 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?
>
> Kevin Simonson

Sounds almost like you want a visitor pattern instead, or an 
intermediate object:

public class SearchResult {
    public boolean isSingleArray() { ... }
    public boolean isMultipleArray() { ... }

    // Throws IllegalStateException if !isSingleArray
    public SingleArray getSingleArray() { ... }
    // Throws IllegalStateException if !isMutipleArray
    public MultipleArray getMultipleArray() { ... }

}

Alternatively, or conjointly, you can use the visitor pattern.

[toc] | [prev] | [next] | [standalone]

#9789

In article <3iYsq.9363$zi2.7579@newsfe10.iad>, 
newsgroup.nospam@virtualinfinity.net says...

> Sounds almost like you want a visitor pattern instead, or an 
> intermediate object:
> 
> public class SearchResult {
>     public boolean isSingleArray() { ... }
>     public boolean isMultipleArray() { ... }
> 
>     // Throws IllegalStateException if !isSingleArray
>     public SingleArray getSingleArray() { ... }
>     // Throws IllegalStateException if !isMutipleArray
>     public MultipleArray getMultipleArray() { ... }
> 
> }

That doesn't seem to be any better than the infamous instaceof-cascade - 
I'd rather say it's even uglier.

Kind regards,
-Wanja-


-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#9795

On 11/8/11 2:15 PM, Wanja Gayk wrote:
> In article<3iYsq.9363$zi2.7579@newsfe10.iad>,
> newsgroup.nospam@virtualinfinity.net says...
>
>> Sounds almost like you want a visitor pattern instead, or an
>> intermediate object:
>>
>> public class SearchResult {
>>      public boolean isSingleArray() { ... }
>>      public boolean isMultipleArray() { ... }
>>
>>      // Throws IllegalStateException if !isSingleArray
>>      public SingleArray getSingleArray() { ... }
>>      // Throws IllegalStateException if !isMutipleArray
>>      public MultipleArray getMultipleArray() { ... }
>>
>> }
>
> That doesn't seem to be any better than the infamous instaceof-cascade -
> I'd rather say it's even uglier.
Being converted to a visitor pattern would be better, granted, but the 
OP was extremely vague on the requirements.

[toc] | [prev] | [next] | [standalone]

#9534

One my essays that gets more than its share of hits discuses when to
use an abstract class and when an interface and when both.

see http://mindprod.com/jgloss/interfacevsabstract.html

-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Capitalism has spurred the competition that makes CPUs faster and 
faster each year, but the focus on money makes software manufacturers 
do some peculiar things like deliberately leaving bugs and deficiencies
in the software so they can soak the customers for upgrades later.
Whether software is easy to use, or never loses data, when the company
has a near monopoly, is almost irrelevant to profits, and therefore 
ignored. The manufacturer focuses on cheap gimicks like dancing paper 
clips to dazzle naive first-time buyers. The needs of existing 
experienced users are almost irrelevant. I see software rental as the 
best remedy.

[toc] | [prev] | [next] | [standalone]

#9788

In article <22857359-211e-443e-9c5d-
6cc2f5bd971b@m19g2000vbm.googlegroups.com>, kvnsmnsn@hotmail.com says...
> 
> I have a method that needs to be able to return either of two very
> different types of data, 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>.

I guess generics could be the remedy to your Problem.

Let me sketch something like this.

Say we have too classes "Foo" and "Bar", both have nothing in commmon.
However, we'd like to have a common interface to obtain both the very 
special result of our query and some common information, say about our 
readLimit and if it was exceeded.
That could look like this:

interface SearchResult{
  <T> Iterable<T> items();
  ReadLimit readLimit();
}

interface ReadLimit{
  int maxItems();
  boolean isExceeded();
}

We then have some consumers, that call some finder to obtain a 
searchResult and get the totally different types from it, whilst also 
using the common information:

class FooConsumer{

 void doSomething(){
  SearchResult<Foo> result 
   = finder.find(Foo.class, new BlueFooPredicate(),new ReadLimit(1000));
  for(Foo foo : result.items()){
   assert Color.Blue.equals(foo.getColor());
  }
  if(result.readLimit().isExceeded()){
   alert("More than "+result.readLimit().maxItems()+" entries found!");
  }
 }
}

class BarConsumer{

 //implementation perhaps injected by a DI-Framework
 private Finder finder; 

 void doSomething(){
  SearchResult<Bar> result 
    = finder.find(Bar.class, 
                  new SteelBarPredicate(), new ReadLimit(500));

  for(Bar bar : result.items()){
   assert Material.Steel.equals(bar.getMaterial());
  }
  if(result.readLimit().isExceeded()){
   alert("More than "+result.readLimit().maxItems()+" entries found!");
  }
 }
}

Kind regards,
Wanja

-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web