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

Groups > comp.lang.java.programmer > #9788

Re: Abstract Class versus an Interface, when no Members in Common

Show key headers only | View raw

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

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Find similar

Thread

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

csiph-web