How to handle a new method in the interface that is not applicable for all classes?

Question

I am faced with an interesting OOD problem: I have an interface with 3 methods:

interface TestInterface {
   String action1();
   String action2();
   String action3();
} 

and 3 classes that implement this interface, so I have a very simple code:

TestInterface testInt;

if(something) {
   testInt = createObject1();
} else if(somethingElse) {
   testInt = createObject2();
} else {
   testInt = createObject3();
}


if(againSomething) {
    testInt.action1();
} else if(againSomethingElse) {
    testInt.action2();
} else {
    testInt.action3();
}

This works fine, however I need to add additional action, but this action only makes sense in the context of one of the classes that implement TestInterface and not in the other two, so if I would to continue the pattern, I would have to add it to the interface, and make a dummy implementation in other classes, but at least the rest of the code would look nice:

interface TestInterface {
   String action1();
   String action2();
   String action3();
   String action4();
}



...
if(someSpecificAction) {
   testInt.action4();
}

I'm not quite keen on that kind of design, so I'm looking for an alternative. I was thinking about creating another interface, just with that method, but I was wondering if I can do better than this code below ?

interface TestInterface {
   String action1();
   String action2();
   String action3();
}

interface NewInterface {
   String action4();

}

TestInterface testInt;

if(something) {
   testInt = createObject1();
} else if(somethingElse) {
   testInt = createObject2();
} else if(something3) {
   testInt = createObject3();
} else {
   testInt = createObject3();
}


if(againSomething) {
    testInt.action1();
} else if(againSomethingElse) {
    testInt.action2();
} else if(something) {
    testInt.action3();
} else {
    NewInterface newI = (NewInterface)testInt;
    newI.action4();
}

Is there a better way to solve this problem ?

Answer 1

Think interfaces from the perspective of the consumer, not from the perspective of implementing classes.

If all consumers will need action4(), then yes it makes sense to add that method to the interface. But what should implementing classes do that do not provide such an action? This will depend entirely on context, but in many cases it might be feasible to do nothing and/or return some default value. In Java, the interface could also provide such a default implementation.

If only some consumers will need action4(), it probably doesn't make sense to add this operation to the interface. Indeed, creating a separate interface could be more appropriate.

Depending on context, it could make sense to let consumers attempt a cast to discover whether an object can be used via this additional interface. A more general approach is to add a method to the original interface like follows:

interface OriginalInterface {
  ...
  @Nullable default AdditionalInterface asAdditionalInterface() {
    return null;
  }
}

interface AdditionalInterface {
  void action4();
}

...
AdditionalInterface ext = instance.asAdditionalInterface();
if (ext != null) {
  ext.action4();
}

This has the advantage that objects do not have to return themselves, but can return other objects as adapters/decorators/proxies/…. Instead of using a nullable approach, it would also be possible to return null objects providing some default behaviour.

In any case, please do not imitate the misfeature of java.util.Iterator and others to raise an UnsupportedOperationException for unavailable methods. This approach is problematic because it is impossible to query in advance whether an operation is available. If an interface declares a method, and an object implements this interface, then all those methods should be usable. Anything else likely violates the Liskov Substitution Principle.

Answer 2

You could have two interfaces: OldInterface and NewInterface, which is derived from OldInterface and implements an additional new method. Two of your classes implement only OldInterface, and a third implements NewInterface. If your code requires the new method then obviously it can only use objects implementing NewInterface.

Another possibility is that you add two methods to the original interface and don't create a new one: Bool implementsAction4() and String action4(). What's ugly is that all classes implementing the interface MUST have at least a stub implementation for action4() returning "" for example. And the caller must know to check implementsAction4() and no compile time checking is possible.

(Objective C has "optional" methods in interfaces that need no implementation. Before you call an optional method, you have to check whether it is nil or not. Which also means it's easy to know that a method is implemented and use that. So you can disable the menu item that would change the colour of an arbitrary object if that object's "setColor" method is nil. Swift allows you to try to cast objects to interfaces, giving nil if the object doesn't implement the interface. So you can write "if let action4Object = myObject as? NewInterface { call action4Object.action4 }", the as? is a cast that may fail and return nil. as! is a cast that is guaranteed to crash on failure. )