Alternatives to downcasting when implementations have unique methods [closed]

Question

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.

Closed 9 years ago.

I have the following Issue. Where I have to cast inside of the makeLeftTurnMethod... this looks very ugly to me.. Is there a way where I don't have to do this?

public interface Car(){
   public void turnRight();
   public void turnLeft();
   public void go();
}
public class LuxuryCare implements Car(){
   public void systemCheckRightSideClear();
   public void systemCheckLeftSideClear();
}
public class UsedCar implements Car(){
   public void personCheckRightSideClear();
   public void personCheckLeftSideClear();
}

public interface Run{
  public void makeLeftTurn();
}
public class RunLuxuryCar implements Run{
  public void makeLeftTurn(Car car){
     car = (LuxuryCar)car;
     car.systemCheckLeftSideClear();
     car.turnLeft();
  }
}

public class RunUsedCar implements Run{
   public void makeLeftTurn(Car car){
       car = (UsedCar)car;
       car.personCheckLeftSideClear();
       car.turnLeft();
   }
}

public void tester(){
    //Could return either used or luxuy car 
    Run run = RunFactory.getInstance(UsedCar);
    Car car = CarFacory.getInstance(usedCar);
    run.makeLeftTurn(car);
}

Answer 1

Here's my best guess at what you intended, with the syntax errors fixed and using generics to eliminate the casts:

public static interface Car{
    public void turnRight();
    public void turnLeft();
    public void go();
 }

 public abstract class LuxuryCar implements Car{
    public void systemCheckRightSideClear(){}
    public void systemCheckLeftSideClear(){}
 }

 public abstract class UsedCar implements Car{
    public void personCheckRightSideClear(){};
    public void personCheckLeftSideClear(){};
 }

 public interface Run<T extends Car> {
   public void makeLeftTurn(T car);
 }

 public class RunLuxuryCar implements Run<LuxuryCar>{
   @Override
   public void makeLeftTurn(LuxuryCar car){
      car.systemCheckLeftSideClear();
      car.turnLeft();
   }
 }

 public class RunUsedCar implements Run<UsedCar>{
    @Override
    public void makeLeftTurn(UsedCar car){
        car.personCheckLeftSideClear();
        car.turnLeft();
    }
 }

Answer 2

The simple answer is that your interfaces should always express all operations that can be performed. If it doesn't make sense for some implementations to implement some methods, then your abstraction is wrong. In this case, your problem suggests that your Car interface needs both isLuxuryCar() and isUsedCar() methods so that you can tell the difference, in addition to the appropriate methods that need to be invoked for each one.

Going a step further, this isn't what inheritance is really for. What you've shown is something I'd expect to find in a textbook or a Java primer, and it's a wrong view of what inheritance is for. Inheritance and polymorphism are all about code reuse, and I find that inheritance relationships are discovered much more often than they're planned. You discover them when you find that you're writing similar code in related objects, at which point you extract a common superclass from them to consolidate the code into one place.