Producing an abstract collection from an abstract collection

Question

This issue has been bugging me for a while. Abstractly speaking, regardless of language, there are often situations when you want to have a method like this:

Collection method(Collection c) {
    // select some elements from c based on some filter 
    // and return a new collection
}

Now, Collection is in this case some abstract class (Like say IList in C# or List in Java) with several implementations. I've been wondering what exactly is the right procedure to produce the abstract collection?

Is it ok to create a concrete collection inside the method and return it? Like:

Collection method(Collection c) {
   Collection cc = new ConcreteCollection();
   // select some elements from c based on some filter 
   return cc;
}

This of course puts a constraint on the resulting collection and will produce problems in case, for some reason, we want to cast the result of the method to a different concrete collection than the one used inside the method.

Or, use reflection to determine the actual concrete type of c and create an instance of that class:

Collection method(Collection c) {
   Collection cc = c.getClass().newInstance();
   // select some elements from c based on some filter 
   return cc;
}

For some reason this does not seem very "elegant" to me. I would greatly appreciate some insight in this matter.

Answer 1

(Speaking for java). The reason you're returning Collection (an interface) rather than a concrete type (such as ArrayList) is that you're telling the user that they shouldn't care about what the actual concrete type being used is. This leaves you free to choose the appropriate type for your library/api.

If you're enforcing a particular concrete class, then you should be returning that concrete class, rather than the interface.

So, they shouldn't be casting your return type to anything else other than Collection. See When should I return the Interface and when the concrete class?.

Answer 2

In Java, there are actually some good examples of how to do this in the java.util.Collections class. Instead of taking a Collection and returning a Collection, the key methods take two collections, the "src" and the "dest". For example, Look at the signature of the copy method:

public static <T> void copy(List<? super T> dest, List<? extends T> src)

This puts the responsibility of instantiating the destination list on the caller.

I think you could do the same thing when you want to create a method that acts on a src Collection and puts the results into a destination Collection (rather than Lists).

I agree with Matthew Farwell's answer that you probably just want to return the interface and utilize that, but for the times when you really do need to work with a specific implementing class you can do it the same way the Collections class does it.

Answer 3

One approach you could take is to create a Collection implementation that delegates calls through to the original Collection. This defers the potentially expensive operation of filtering a large Collection until you need to explicitly read elements. It also saves memory.

Example

public interface Filter<T> {
  boolean include(T t);
}

public class FilterCollection<T> implements Collection<T> {
  private final Collection<T> orig;
  private final Filter<T> filter;

  public FilterCollection(Collection<T> orig, Filter<T> filter) {
    this.orig = orig;
    this.filter = filter;
  }

  public int size() {
    int sz = 0;

    for (T t : orig) {
      if (filter.include(t)) {
        ++sz;
      }
    }

    return sz;
  }

  public boolean contains(Object o) {
    return o instanceof T && filter.include((T) o) && orig.contains(o);
  }

  public boolean add(T t) {
    if (!filter.include(t)) {
      throw new IllegalArgumentException("Element lies outside filter bounds.");
    }

    orig.add(t);
  }
}

Answer 4

The caller should assume a given type of Collection is returned.

Instead it should either copy to the desired type or pass the desired type.

e.g.

Set<T> set2 = new HashSet<T>(filter(set));
List<T> list2 = new ArrayList<T>(filter(list));

or

filter(set2, set); // the target collection is passed.
filter(list2, list);

Answer 5

As far as I can understand, you want to know how to make a method that accepts generic list and returns another modified generic list.

So, my advice will be to use an abstract type that implements method to modify its state.

IList<object> list = new List<object>();

list.Add(new object());
list.Remove(obj);

Or as showed above, instantiate a list that implements IList (or the Java equivalent) work with this instance and return the result as a IList

Edit

If you want to filter some item from a list to a new one, generics can help (I don't know if this feature exists in Java).

    public IList<T> Filter<T>(IList<T> list)
    {
        var result = new List<T>();
        result.Add(list[0]); // Or whatever filtering method
        return result;
    }

Answer 6

To the question about ConcreteCollection, it is definitely allowable.
To the concern about having a different concrete collection expected, there are a few ways to go around the problem:

Change the return type of the method. Example:

ConcreteCollection method(Collection c){
    ConcreteCollection cc=new ConcreteCollection
    for(Object x: c){
        //do something
    }
    return cc
}

Make use of polymorphism. Example:

Collection x=method(c)
x.add(new Object) //add is a method defined within the abstract Collection

Use some utilities to cast the type. Example:

LinkedList h=Collections.toLinkedList(method(c))

Hoped my answer helped. ^^

Answer 7

If you want your method to accept as many different collection types as possible, and you want to be sure that the result is the same implementation type as what you put in, you might want to use a void method which directly modifies the supplied collection. For instance:

import com.google.common.base.Predicate;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.Iterator;
import java.util.List;

public class Testy {

    private static <T> void filter(Iterable<T> collection, Predicate<T> filter) {
        Iterator<T> iterator = collection.iterator();
        while (iterator.hasNext()) {
            if (!filter.apply(iterator.next())) { // Condition goes here
                iterator.remove();
            }
        }
    }

    public static void main(String... args) {
        List<String> list = new ArrayList<String>();
        list.addAll(Arrays.asList("A", "B", "C", "D"));

        filter(list, new Predicate<String>() { // Anonymous filter (predicate)
            @Override public boolean apply(String input) {
                return input.equals("B");
            }
        });

        System.out.println(list); // Prints ["B"]
    }

}

The helper method filter takes an Iterable, the simplest type required for iterating over something. Apply the filter to each element, and if the predicate (filter) returns false, remove that element from the underlying collection with Iterator.remove().

The Predicate<T> interface here comes from Google. You can easily write your own if you don't wish to import it. The only required method is apply(T) which returns a boolean. Either that, or just write your condition directly inside the loop and get rid of the second parameter.

This method is the most efficient if your original collection is mutable and you don't wish to keep any intermediate results.

Another option is to use Google Collections Collections2.filter(Collection<E>, Predicate<E>) which returns a Collection<E> just like in your question. Similarly, the Iterables class will do the same thing, but create lazy iterables where the filters are only applied when actually doing the iterating.