开发者

Java: substituting a subclass/subtype of a parameter when overiding a method?

So I asked this question before but I had a mistake in the code which most people picked up on, rather than the problem itself.

Anyway, I'm trying to override an interface method in a class. However, I want the type of the parameter in the overriding method to be a subclass of the type of the parameter as defined in the overriden method.

The interface is:

public interface Observer {
 public void update(ComponentUpdateEvent updateEvent) throws Exception;
}

While the class that overrides this method is:

public class ConsoleDrawer extends Drawer {

//...

 @Override
 public void update(ConsoleUpdateEvent updateEvent) throws Exception {
  if (this.componentType != updateEvent.getComponentType()) {
   throw new Exception("ComponentType Mismatch.");
  }
  else {
   messages = updateEvent.getComponentState(); 
  }
 }

//...

}

ConsoleUpdateEvent is a subclass of ComponentUpdateEvent.

Now, I could just have the update() method in ConsoleDrawer take a ComponentUpdateEvent as a parameter and then cast it to a Con开发者_开发知识库soleUpdateEvent but I'm looking for a slightly more elegant solution if possible. Anyhelp would be appreciated. Thank you.


You can't. This is not Eiffel. The problem being that you could use the interface to call the implementation method with an incompatible type. So covariant parameters are not allowed. Contravariant parameters aren't allowed either, but it is easier to provide an overload. Covariant return type is allowed (since 1.5).

You could parameterise the interface:

public interface Observer<T extends ComponentEvent> {
    void update(T event) throws Exception;
}

Alternatively, use a more meaningful interface:

public interface ConsoleObserver {
    void update(ConsoleEvent event) throws Exception;
}


Going by OOP principles, a sub-class should be usable in exactly the same way as the parent class. e.g.

Observer ob = new ConsoleDrawer();
ob.update(new ComponentUpdateEvent()); // This needs to work always.

However, if Java were to allow you to use a subtype of the parameter when overriding a method, then it would expose your code to cases where the overriding method (in the subclass) would reject the input parameter (ComponentUpdateEvent in the above case). Thus, you would never be sure whether its safe to call update() or not on an Observer reference.

Hence, the only logical solution is to accept the parent class parameter, type-check it and then cast it to the required subtype.


You could try the following. The @Deprecated produces a warning if the compiler knows you will be calling the first method rather than the second.

@Override @Deprecated
public void update(ComponentUpdateEvent updateEvent) {
    // throws a ClassCastException if its not the right type.
    update((ConsoleUpdateEvent) updateEvent); 
}

public void update(ConsoleUpdateEvent updateEvent) {
    messages = updateEvent.getComponentState(); 
}

BTW: You shouldn't just place throws Exception on everything. Its certainly not best practice.

EDIT: I have implemented a different solution to this problem which works well with OSGi but can work anywhere.

An Observer registers itself with a Broker and expects to find methods with an annotation such as ObserverCallback.

e.g.

public class ConsoleDrawer extends Drawer {
 @ObserverCallback
 public void onConsoleUpdateEvent(ConsoleUpdateEvent updateEvent) {
   messages = updateEvent.getComponentState(); 
 }
}

public class DeviceDrawer extends Drawer {
 @ObserverCallback
 public void onDeviceUpdateEvent(DeviceUpdateEvent updateEvent) {
   // do something.
 }
}

In the first case, the broker finds a method with the @ObserverCallback which takes one argument. This is the only type the Broker will pass it. The second class expects a different type. Observers can have multiple method/types allowing them to handle different messages in different methods appropriate to that type. You also know you will never receive a data type you don't expect.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜