How do I perform an action on each element of a List and return the result (without affecting the original of course)?_问答_开发者

How do I write a static method in Java that will take a List, perform an action on each element, and return开发者_如何学C the result (without affecting the original of course)?

For example, if I want to add 2 to each element what goes in the ... here? The concrete return type must be the same, e.g. if my List is a LinkedList with values 1,2,3 I should get back a LinkedList with values 3,4,5. Similarly for ArrayList, Vector, Stack etc, which are all Lists.

I can see how to do this using multiple if (lst instanceof LinkedList) ... etc... any better way?

import java.util.List;

public class ListAdd {       

    static List<Integer> add2 (List<Integer> lst) {

    ...

        return result;
    }
}

There are already many answers, but I'd like to show you a different way to think of this problem.

The operation you want to perform is known as map in the world of functional programming. It is something we do really all the time in functional languages.

Let M<A> be some kind of container (in your case, M would be List, and A would be Integer; however, the container can be lots of other things). Suppose you have a function that transforms As into Bs, that is, f: A -> B. Let's write this function as of type F<A, B>, to use a notation closer to Java. Note that you can have A = B, as in the example you give (in which A = B = Integer).

Then, the operation map is defined as follows:

M<B> map(M<A>, F<A, B>)

That is, the operation will return a M<B>, presumably by applying F<A, B> to each A in M<A>.

In practice...

There's a brilliant library developed by Google, called Guava, which brings lot's of functional idioms to Java.

In Guava, the map operation is called transform, and it can operate on any Iterable. It has also more specific implementations that work directly on lists, sets, etc.

Using Guava, the code you want to write would look like this:

static List<Integer> add2(List<Integer> ns) {
  return Lists.transform(ns, new Function<Integer, Integer>() {
    @Override Integer apply(Integer n) { return n + 2; }
  }
}

Simple as that.

This code won't touch the original list, it will simply provide a new list that calculates its values as needed (that is, the values of the newly created list won't be calculated unless needed -- it's called a lazy operation).

As a final consideration, it is not possible for you to be absolutely sure that you will be able to return exactly the same implementation of List. And as many others pointed out, unless there's a very specific reason for this, you shouldn't really care. That's why List is an interface, you don't care about the implementation.

Fundamentally, the List interface doesn't make any guarantees that you'll have a way to duplicate it.

You may have some luck with various techniques:

Using clone() on the passed in List, although it may throw, or (since it is protected in Object) simply not be accessible
Use reflection to look for a public no-argument constructor on the passed-in List
Try to serialize and deserialize it in order to perform a "deep clone"
Create some sort of factory and build in knowledge of how to duplicate each different kind of List your code may encounter (What if it's a wrapper created by unmodifiableList(), or some oddball custom implementation backed by a RandomAccessFile?)
If all else fails, either throw, or return an ArrayList or a Vector for lack of better options

You could use reflection to look for a public zero-arg constructor on the result of lst.getClass() and then invoke() it to obtain the List into which you'll place your results. The Java Collections Framework recommends that any derivative of Collection offer a zero-arg constructor. That way, your results we be of the same runtime class as the argument.

Here is a variant which does neither copies nor modifies the original list. Instead, it wraps the original list by another object.

public List<Integer> add2(final List<Integer> lst) {
    return new AbstractList<Integer>() {
        public int size() {
            return lst.size();
        }
        public Integer get(int index) {
            return 2 + lst.get(index);
        }
    };
}

The returned list is not modifiable, but will change whenever the original list changes. (This implements the iterator based on index access, thus it will be slow for a linked list. Then better implement it based on AbstractSequentialList.)

Of course, the resulting list will obviously not be of the same class as the original list.

Use this solution only if you really only need a read-only two added view of your original list, not if you want a modified copy with similar properties.

The whole point of using an interface, in this case List, is to abstract the fact that the implementation is hidden behind the interface.

Your intention is clear to me, however: the Clonable interface supports creating a new instance with the same state. This interface might not be defined on your List.

Often it's a good idea to rethink this situation: why do you need to clone the List in this place, this class? Shouldn't your list-creator be responsible for cloning the list? Or shouldn't the caller, who knows the type, make sure he passes in a clone of his list?

Probably, if you look for the semantics as you defined it, you can implement all your supported Lists:

static Vector<Integer> addTwo(Vector<Integer> vector) {
    Vector<Integer> copy = null; // TODO: copy the vector
    return addTwo_mutable(copy);
}
static ArrayList<Integer> addTwo(ArrayList<Integer> aList) {
    ArrayList<Integer> copy = null; // TODO: copy the array list
    return addTwo_mutable(copy);
}
static LinkedList<Integer> addTwo(LinkedList<Integer> lList) {
    LinkedList<Integer> copy = null; // TODO: copy the linked list
    return addTwo_mutable(copy);
}

private <T extends List<Integer>> static T addTwo_mutable(T list) {
    return list; // TODO: implement
}

Even, when you don't support a data-type, you'll get a nice compiler error that the specified method does not exists.

^{(code not tested)}

Just to show you that what you want to do is not possible in the general case, consider the following class:

final class MyList extends ArrayList<Integer> {
  private MyList() {
    super.add(1);
    super.add(2);
    super.add(3);
  }
  private static class SingletonHolder {
    private static final MyList instance = new MyList();
  }
  public static MyList getInstance() {
    return SingletonHolder.instance;
  }
}

It is a singleton (also, a lazy, thread-safe singleton by the way), it's only instance can be obtained from MyList.getInstance(). You cannot use reflection reliably (because the constructor is private; for you to use reflection, you'd have to rely on proprietary, non-standard, non-portable APIs, or on code that could break due to a SecurityManager). So, there's no way for you to return a new instance of this list, with different values.

It's final as well, so that you cannot return a child of it.

Also, it would be possible to override every method of ArrayList that would modify the list, so that it would be really an immutable singleton.

Now, why would you want to return the exact same implementation of List?

OK well someone mentioned reflection. It seems to be an elegant solution:

import java.util.*;
public class ListAdd {

    static List<Integer> add2 (List<Integer> lst) throws Exception {

        List<Integer> result = lst.getClass().newInstance();
        for (Integer i : lst) result.add(i + 2);

        return result;
    }
}

Concise, but it thows an checked exception, which is not nice.

Also, wouldn't it be nicer if we could use the method on concrete types as well, e.g. if a is an ArrayList with values 1, 2, 3, we could call add2(a) and get an ArrayList back? So in an improved version, we could make the signature generic:

static <T extends List<Integer>> T add2 (T lst) {
    T res;
    try {
        res = (T) lst.getClass().newInstance();

    } catch (InstantiationException e) {
        throw new IllegalArgumentException(e);
    } catch (IllegalAccessException e) {
        throw new RuntimeException(e);
    }

    for (Integer i : lst) res.add(i + 2);
    return res;
}

I think throwing a runtime exception is the least worst option if a list without a nullary construcor is passed in. I don't see a way to ensure that it does. (Java 8 type annotations to the rescue maybe?) Returning null would be kind of useless.

The downside of using this signature is that we can't return an ArrayList etc as the default, as we could have done as an alternative to throwing an exception, since the return type is guaranteed to be the same type as that passed in. However, if the user actually wants an ArrayList (or some other default type) back, he can make an ArrayList copy and use the method on that.

If anyone with API design experience reads this, I would be interested to know your thoughts on which is the preferable option: 1) returning a List that needs to be explicity cast back into the original type, but enabling a return of a different concrete type, or 2) ensuring the return type is the same (using generics), but risking exceptions if (for example) a singleton object without a nullary constructor is passed in?