Naming clash in two interfaces... what can I do?

This is a headache. I must implement two interfaces, let's call it IFace1 and IFace2. Both requires a method public void remove(); However, the two interfaces have different semantics for the remove() method because they are to remove entries from different queues.

Is there a way to implement two remove methods in my implementation (they have exact the same signature) but to specify which interface it belongs to? With class name conflicts, java uses namespace to differentiate them. Is there something similar for methods? Obviously, doing this won't even compile:

public void my.own.IFace1.remove() {...}

public void john.called.it.IFace2.remove() {...}

The only hope is that I created IFace1, so my last resort would be to rename "remove" to "delete" or something. This is ugly and I hate to do it unless I have to. Thanks.

[863 byte] By [emanresua] at [2007-11-27 11:50:49]
# 1

> This is a headache. I must implement two interfaces,

> let's call it IFace1 and IFace2. Both requires a

> method public void remove(); However, the two

> interfaces have different semantics for the remove()

> method because they are to remove entries from

> different queues.

Then you cannot properly implement both interfaces in a single class.

> Is there a way to implement two remove methods in my

> implementation (they have exact the same signature)

> but to specify which interface it belongs to?

No.

jverda at 2007-7-29 18:34:15 > top of Java-index,Java Essentials,Java Programming...
# 2

This approach may suffice:

interface Face1 {}

interface Face2 {}

class X {

public Face1 face1View() {...}

public Face2 face2View() {...}

}

These methods present views of your X object, in a similar way to the

keySet, entrySet and values methods of Map. This is a common technique.

BigDaddyLoveHandlesa at 2007-7-29 18:34:15 > top of Java-index,Java Essentials,Java Programming...
# 3

BDLH, thanks for the suggestion, however, I am not sure if this would solve my problem. The problem lies in the fact that both interfaces have a method called remove() and it causes ambiguity. Whether I cast the object to Face1 or Face2, I still end up with one single remove() method in the implementation class, and the method needs to carry two sets of semantics...

Is this a limitation of Java? Maybe in a future version of JDK, they will allow namespace for method names?

emanresua at 2007-7-29 18:34:15 > top of Java-index,Java Essentials,Java Programming...
# 4

this has nothing to do with it being Java. In C++ (for example) you'd have the same thing if you'd extend 2 classes, both containing methods with identical signatures.

jwentinga at 2007-7-29 18:34:15 > top of Java-index,Java Essentials,Java Programming...
# 5

> Is this a limitation of Java? Maybe in a future

> version of JDK, they will allow namespace for method

> names?

I really hope not.

kajbja at 2007-7-29 18:34:15 > top of Java-index,Java Essentials,Java Programming...
# 6

How about not implementing both interfaces, and instead use aggregation of two objects in some container?

CeciNEstPasUnProgrammeura at 2007-7-29 18:34:15 > top of Java-index,Java Essentials,Java Programming...
# 7

About the only approach that springs to mind is to create two inner class instances (probably anonmous) each of which implements one of the interfaces.

So:

public class MyClass {

public IFace1 if1 = new IFace1() {

// implement other methods - probably delegating to main class

public void remove() {

// remove semantics one

}

};

public IFace2 if2 = new IFace2() {

public void remove() {

// remove semantics 2

}

....

}

malcolmmca at 2007-7-29 18:34:15 > top of Java-index,Java Essentials,Java Programming...
# 8

> BDLH, thanks for the suggestion, however, I am not

> sure if this would solve my problem.

Works for me:

interface Face1 {

void remove();

}

interface Face2 {

void remove();

}

class X {

public Face1 face1View() {...}

public Face2 face2View() {...}

}

//elsewhere:

X x = ...

x.face1View().remove();

x.face2View().remove();

Does this solve your problem? Probably, but you've never described it well enough to see if this approach captures your design.

(I notice that this is consistent with the code in the previous reply.)

BigDaddyLoveHandlesa at 2007-7-29 18:34:15 > top of Java-index,Java Essentials,Java Programming...