A drawback of Don's approach is that it extends from ArrayList
. That may be good enough for now, but what happens when you want to use a different List
implementation? You could make a NoNullsLinkedList
and a NoNullsCopyOnWriteArrayList
, etc, but then you wind up with a bunch of little classes that differ only in their extends
clause. It might be better to create a List
wrapper that doesn't accept null values. For example:
public class NonNullList<E> extends AbstractList<E> {
private final List<E> delegate;
public NonNullList(List<E> delegate) {
this.delegate = delegate;
}
@Override
public E get(int index) {
return delegate.get( index );
}
@Override
public int size() {
return delegate.size();
}
@Override
public E set(int index, E element) {
return delegate.set( index, element );
}
@Override
public void add(int index, E element) {
if( element != null ) {
delegate.add( index, element );
}
}
@Override
public E remove(int index) {
return delegate.remove( index );
}
}
It's more code, but now you have the flexibility of choosing a List
implementation when you create the object.
A possible problem is that you can still insert null
s into the underlying List
object. Don's approach doesn't have the same limitation.