Returning an interface object from a method without instantiating an (unknown) concrete type

Question

I'm sure there's some solution or pattern to this but i'm having trouble articulating the question to find the right answer.

I have an interface, ICar:

public interface ICar {
void SetMake(String make);
String GetMake();
}

I have a class, Car:

public class Car implements ICar {
private String make;

public void SetMake(String make) { this.make = make; }

public String GetMake() { return make; }

And I have a method in another class, which does not know about Car. In the spirit of polymorphism I'd like this method to return an ICar, so that someone could create their own implementation of ICar and utilize the method for their car:

...//class preamble
public ICar myMethod() {
    ICar myCar = new ICar();
    myCar.SetMake("Ferrari");
    return myCar;
}

I'm not sure why something like this can't work. As ICar contains the method SetMake, every implementation must also contain this method. Surely the jvm could in some way queue up the method calls and then run them when a concretion of the methods is available?

Another idea would be to pass a newly created implementation of ICar as a parameter to myMethod and call its methods, but I feel like this may not be such a clean implementation, as I would need to create an instance of Car each time. Also if there is no parameter-less constructor, i would have to instantiate it with dummy data (also not clean).

I feel like i'm lacking some understanding to see how to implement something like this, and was wondering if anyone might be able to help?

Thanks.

Answer 1

One way to do this is to provide the class type as a parameter, and also make it generic:

public <T extends ICar> T myMethod(Class<T> type) {
    try {
        T myCar = type.newInstance(); // T needs a visible no-args constructor
        myCar.SetMake("Ferrari");
        return myCar;
    } catch (Exception e) {
        throw new RuntimeException(e);
    }
}

(note also that I dealt with exceptions by wrapping any in a RuntimeException)

Then you need to call it like this:

Car car = myMethod(Car.class);

A more flexible way is to introduce a factory interface and pass a factory instance to myMethod, which uses it to create a concrete ICar. The factory can still be generic:

public interface ICarFactory<T extends ICar> {
    T createCar();
}

...

public <T extends ICar> T myMethod(ICarFactory<T> factory) {
    T myCar = factory.createCar();
    myCar.SetMake("Ferrari");
    return myCar;
}

...

Car car = myMethod(carFactory);

Answer 2

You need to do:

public ICar myMethod() {
    ICar myCar = new Car();
    myCar.SetMake("Ferrari");
    return myCar;
}

instead of

public ICar myMethod() {
    ICar myCar = new ICar();
    myCar.SetMake("Ferrari");
    myCar.return;
}

this statement: myCar.return; makes almost no sense here... and since ICar is an interface you can not do ICar myCar = new ICar()

Answer 3

You cannot instantiate an Interface, so new ICar() is not an option. For example, the setMake is supposed to set an instance variable, but an Interface has no instance variables.

However, you can do something like:

        return new ICar() {
        String m;
        @Override
        public void setMake(String make)
        {
            m = make;
        }



        @Override
        public String getMake()
        {
            return m;
        }
    };

In this way you are create an object that implements the interface.

While this answer gives a particular example to answer the question (as does simply instantiating a Car object), the larger question about the interface is that one can return any Object that implements in the interface. There are any number of design patterns than allow for delegating creation of objects. One might consider the Factory Pattern for example.

Answer 4

You can't create a new interface but you can return one.

public ICar myMethod() {
    ICar myCar = new Car();
    myCar.SetMake("Ferrari");
    return myCar;
}

Interface means a contract it's basically saying "This is a ICar it can be Car, RedCar and a thousand different implementations but you don't know which" . This is the meaning of polymorphism whoever uses myMethod has no idea which car he gets, he can only know the contract but not how they are implemented.

Answer 5

Not really sure if I understand what you're after exactly, but I think what you really want to do is inherit your Car from an abstract base class, so that someone else can implement other types of vehicles.

Something like this:

public abstract class Vehicle {
    public abstract void SetMake(String make);
    public abstract String GetMake();
}

public class Car extends Vehicle {
    private String make;
    public void SetMake(String make) { this.make = make; }
    public String GetMake() { return make; }
}

public class Truck extends Vehicle {
    private String make;
    public void SetMake(String make) { this.make = make; }
    public String GetMake() { return make; }
}



public Vehicle myMethod() {
    Vehicle myCar = new Truck();
    myCar.SetMake("Ferrari");
    return myCar;
}    

Answer 6

For the method myMethod() you have stated

"In the spirit of polymorphism I'd like this method to return an ICar, so that someone could create their own implementation of ICar and utilize the method for their car:"

What I understand from this is you wish to make myMethod() work with different concrete types of ICar.

Objects are created when you use new operator. Your existing code would not compile as you can not instantiate the object of Interfaces. To fix the compile error I would not like you to to create the concrete car objects:

ICar car = new Car(); // this will solve compile error but avoid doing this in your code

Avoid new operator, let the user of your code use new and inject the concrete implementations (you may not even know the concrete implementations as they are user dependent, users of your code).

Change the method as below

...//class preamble
public ICar myMethod(ICar myCar, String make) {
    myCar.SetMake(make);
    return myCar;
}

I would suggest you to study : DIP principle and dependency injection, code to interface.