Question

This isn’t exactly the definition of implicit type conversion, but I’m curious how many standards I’m breaking with this one…

I’m creating an abstract class in Java that basically casts its variables depending on a string passed into the constructor.

For example:

public abstract class MyClass {

    Object that;

    public MyClass(String input){
        if("test1".equals(input){
            that = new Test1();
        }
        else{
            that = new Test();
        }
    }

    public void doSomething(){
        if(that instanceof Test1){
            //specific test1 method or variable
        } else if(that instanceof Test2)}
            //specific test2 method or variable
        } else {
            //something horrible happened
        }
    }
}

You see what I’m getting at? Now the problem I run into is that my compiler wants me to explicitly cast that into Test1 or Test2 in the doSomething method – which I understand, as the compiler won’t assume that it’s a certain object type even though the if statements pretty much guarantee the type.

I guess what I’m getting at is, is this a valid solution?

I have other classes that all basically do the same thing but use two different libraries depending on a simple difference and figure this class can help me easily track and make changes to all of those other objects.

Answer 1

You are right. This is a horrible way to achieve polymorphism in design. Have you considered using a factory? A strategy object? It sounds like what you are trying to achieve can be implemented in a more loosely-coupled way using a combination of these patterns (and perhaps others).

For the polymorphism of doSomething, for example:

interface Thing {
    public void doThing();
}

class Test1 implements Thing {
    public void doThing() {
        // specific Test1 behavior
    }
}

class Test2 implements Thing {
    public void doThing() {
        // specific Test2 behavior
    }
}

class MyClass {

    Thing _thing;

    public void doSomething() {
        _thing.doThing();    // a proper polymorphism will take care of the dispatch,
                             // effectively eliminating usage of `instanceof`
    }
}

Of course, you need to unify the behaviors of Test1 and Test2 (and other concrete Thing classes, present and planned) under a set of common interface(s).

PS: This design is commonly known as Strategy Pattern.