31

Is it possible to generically parameterize a method accepting EITHER ClassA OR InterfaceB ?

Does Not Compile Due to | Pseudocode

public <T extends Number | CharSequence> void orDoer(T someData){ // ... }

i.e. instead of writing multiple method signatures, I would like this one method to accept either a Number or CharSequence as an argument

Should Pass with a Number OR CharSequence argument

orDoer(new Integer(6));
int somePrimitive = 4;
orDoer(somePrimitive);
orDoer("a string of chars");
Oliver Charlesworth
  • 267,707
  • 33
  • 569
  • 680
Cel
  • 6,467
  • 8
  • 75
  • 110
  • 4
    What would you do inside that method that cannot be done with two separate methods that accept `Number` or `CharSequence` respectively and then delegate to a third, private method to do the work? – Philipp Reichart Nov 30 '11 at 17:42
  • 1
    I agree the gains are insubstantial if I am dealing with two types, but it would seem a nice concise way to delegate more parameter types (that do not share a usable supertype) – Cel Nov 30 '11 at 17:49
  • 1
    You should check out [Ceylon](http://ceylon-lang.org/documentation/1.1/introduction/)'s union types. ;) – Anonsage Apr 18 '15 at 04:08

3 Answers3

20

If you really want to do that, you'll need to wrap youur accepted classes inside a custom class of your own. In your example case, probably something like:

public class OrDoerElement {
    private final Number numberValue;
    private final CharSequence charSequenceValue;

    private OrDoerElement(Number number, CharSequence charSequence) {
        this.numberValue = number;
        this.charSequenceValue = charSequence;
    }

    public static OrDoerElement fromCharSequence(CharSequence value) {
        return new OrDoerElement(null, value);
    }

    public static OrDoerElement fromNumber(Number value) {
        return new OrDoerElement(value, null);
    }
}

And your orDoer method becomes:

public void orDoer(OrDoerElement someData) { .... }

Then you can build one of those and use in your method using either:

orDoer(OrDoerElement.fromCharSequence("a string of chars"));
orDoer(OrDoerElement.fromNumber(new Integer(6)));

But honestly, that sounds a bit too complex and too much work just to be able to call a method with different parameter types. Are you sure you can't achieve the same using two methods, and a third method for the common logic?

Guillaume
  • 22,694
  • 14
  • 56
  • 70
  • Thanks for the answer! I realize now i didnt explain my use-case properly - I was looking for something very similar to `T extends ClassA | InterfaceB` because i wanted the caller of my method to be able to pass in their type as-is (Integer or String etc directly). That is, to provide a `store(T data)` method, which would accept all kinds of types having the characteristic of being fully re-constructable from .toString() and a standard single-parameter instantiation (Number, CharSequence, Date and many more persistable types). – Cel Nov 30 '11 at 18:43
  • i.e. another way I could have asked the question is why is there no shared type - before Object - for Number, CharSequence and other native types, which would characterise them as those Uniconstructables or whatever you would want to call them .. (hope it makes sense) – Cel Nov 30 '11 at 18:46
  • Yes, I understand, this kind of super-super class would indeed prove useful in some cases – Guillaume Nov 30 '11 at 23:27
1

For the original question:

public void orDoer(Object someData){
    assert someData instanceof Number || someData instanceof CharSequence;

    // ...
}

In your more specific case, the assert statement should just use introspection to clarify if the object has the specifics you want, i.e. check for a constructor from String, probe to create a new instance of the object from the toString() result of the incoming object, and compare both for equality:

public void orDoer(Object someData) {
    assert isUniconstructable(someData);
}

public static boolean isUniconstructable(Object object) {
    try {
        return object.equals(object.getClass().getConstructor(String.class)
            .newInstance(object.toString()));
    } catch (InstantiationException | IllegalAccessException | InvocationTargetException
            | NoSuchMethodException| RuntimeException e) {
        return false;
    }
}

(Because of the exceptions that may be thrown, we need to wrap the assert test into its own function.)

Be aware that introspection may break due to Android’s ProGuard code compression which rewrites the class names, and instead of YourClass just a Class, i.e. Q, is stored in the database, and when you want to restore it with a later version of your app which has more classes, class Q is something different then. See the ProGuard website for more information on this; I just wanted to notify that you should be aware of this when using introspection on Android.

Matthias Ronge
  • 9,403
  • 7
  • 47
  • 63
1

Is using an anonymous abstract class an option for you? When I need type safe parameters or return types, I use some variant of the code below. That being said, I agree with the other comments here, and am curious what benefit you really derive when you're enforcing a type safety for a group of objects that don't have all that much in common. 

public abstract class Doer<T> {

  public void do(T obj) {
    // do some stuff. 
  }

}

// calling method

new Doer<Number>(){}.do(new Integer(5));
Fil
  • 2,016
  • 18
  • 29