Subclassing interfaces

Let say I have two interfaces A and B. They have all but a couple of methods in common. I create a new interface C, and both A and B extends C.

We know have the change to implement A, B but also C. And that really doesn't make sense (C is an incomplete contract, not very nice to implement it!)

Ok, I can skip the 'public' bit for C, so only classes in the same package may implement it. Or I can declare it depracated. But still I don't like that. Any idea or should I simple change the entire design?

Thanks,

Renato

Could classes in other packages benefit from having methods like:

void f(C c) //pass me either kind of object

Maybe. But I still need to be sure that the object you pass implements either A or B, C is not enough.

Originally posted by Renato Losio:
Maybe. But I still need to be sure that the object you pass implements either A or B, C is not enough.

Could you give a concrete example? I think you're expecting too much from Java's static type structure. Take package java.util for example. Both interfaces List and Set extend Collection. Suppose no concrete class is meant to only implement Collection (I believe there is no such class the J2SE). There's no way to enforce this -- but so what? Does anything bad happen if I write a class tomorrow that directly implements Collection? Something bad would happen if I had written a method like:

That code is making a closed world assumption -- every collection is either a List or a Set. That's bad coding practice for a number of reasons.

In conclusion, if your code is open-ended, I don't see the problem caused by exposing the base interface. Just avoided code that makes assumptions like the above.

Thanks for your interesting example. I would avoid to write a method as the one you wrote. And you probably convinced me that there's no need to strongly enforce that. But sometime would be useful:

let's say I have an interface 'Connector' for a given protocol version 3.4 . Someone changes the protocol and I have a new interface 'Connector35', that complies to the new reqs and have a new method + a modified signature of a previous one.

I would like to have something like a general 'Connector' (with 8 methods) and two subclasses according to the protocol version (for the other 2 methods).

It would be great if someone else add one more subclass in the future for a new protocol version, but I would be more happy if I am sure that EVERY class is not implementing the C interface only. That would be a useless contract. So a useless interface.

You are observing the devastational effects of static contract inheritance. At least I (and others) hope to address this at some point in the future, but until then, it would help merely to understand the issue at hand, so that you can make informed decisions about how and when to concede.

The reasoning is quite verbose and it often helps instead to first identify which common premises that each party in the discussion has so that they have a platform from which to explore. I do this on live chat (IRC, etc.) and/or in person - I have had no success on internet forums so I refrain from doing so.

Please feel free to contact me if you wish to explore this issue further.

Originally posted by Tony Morris:
The reasoning is quite verbose and it often helps instead to first identify which common premises that each party in the discussion has so that they have a platform from which to explore. I do this on live chat (IRC, etc.) and/or in person - I have had no success on internet forums so I refrain from doing so.

Tony,
In these forums, your provocative comments stand out like -- what is the Australian saying? -- like a dog's balls. Surely you're not going to leave us dangling like that?

I plan to address the issue, but not on these forums, sorry - only steer in the right direction those who seek it. My comment is aimed primarily at the original poster.