One possible way would be to bind the array's element type to a generic type parameter and tie the processor and the array together early on:
public class ArrayProcessingWrapper<T> {
private final T[] array;
private final ArrayProcessor<T> processor;
public ArrayProcessingWrapper(T[] array, ArrayProcessor<T> processor) {
super();
this.array = array;
this.processor = processor;
}
public void processArray() {
this.processor.process(this.array);
}
}
Another way might be along the lines of functions
public abstract class Processor<T> {
private final Supplier<T[]> arraySupplier;
public Processor(final Supplier<T[]> arraySupplier) {
super();
this.arraySupplier = arraySupplier;
}
public T[] createArray() {
return this.arraySupplier.get();
}
public void processNewArray() {
this.doProcess(this.createArray());
}
protected abstract void doProcess(T[] data);
}
public class BooleanProcessor extends Processor<Boolean> {
public BooleanProcessor(Supplier<Boolean[]> arraySupplier) {
super(arraySupplier);
}
@Override
protected void doProcess(Boolean[] data) {
// Do fancy boolean stuff...
}
}
But also have a look at Iterable<E>
and/or Collection<E>
(of which ArrayList<E>
is what behaves the most like an array) instead of arrays.
To me, it seems like a design flaw if you need to use different logic ("processors") depending on the (runtime) type of an array.