1

I found this question: Two Interface with Same Method Name - Implementation of Methods

So if a class implements two interfaces, there is a problem:

  1. Suppose the interface Foo specifies a Foo method doStuffX(), and interface Bar specifies doStuffY(). Someone implements lets a class FooBar implement booth interfaces.

  2. Later, it is realized that Foo needs access to a doStuffY implementation, but with a different slightly different specification that makes sense in the context of Foo.

  3. Now, when a FooBar is passed to any method that accepts a Foo and relies on doStuffY() may break.

So, my conclusion is that one should not implement more than one interface. Is that correct? Are there any techniques other than inner classes that can be used to add context names to interface methods. I thought of passing Foo and Bar references to them. Are there more ways?

Community
  • 1
  • 1
user877329
  • 6,717
  • 8
  • 46
  • 88
  • "Are there any techniques other than inner classes..." Quite possibly. But you'd have to pick a specific language rather than asking a "language agnostic" question. Also, of course, if it was really a universally bad idea for you to implement multiple interfaces, why do you think languages would allow you to do so? – Damien_The_Unbeliever Dec 30 '15 at 13:24
  • Languages not only allow implementing more than one interface, their standard libraries are full of classes that do so. – el.pescado - нет войне Dec 30 '15 at 14:06
  • 3
    Your conclusion is just plain wrong. "Errors may occur, therefore we should not program". – n. m. could be an AI Dec 30 '15 at 14:21

3 Answers3

2

So, my conclusion is that one should not implement more than one interface

This sounds like throwing the baby out with the bathwater.

While it's true that it may happen that two interfaces may be mutually incompatible, forbidding implementing any two interfaces is overly restrictive solution. The real solution is to put more effort into defining interfaces so that they:

  1. Don't clash with each other
  2. Don't change over time without good reason

That way, the situation you described is unlikely to happen.

In fact, your proposal makes interfaces totally useless. The point of interfaces is to introduce some benefits of multiple inheritance into language with single inheritance. When you allow only one interface to be implemented, interfaces become pointless - when you can implement only one interface, you could just use single inheritance.

el.pescado - нет войне
  • 18,889
  • 4
  • 46
  • 89
  • I don't think interfaces are ever incompatible. You can explicitly implement both interfaces and have two methods with the same name and signature. – usr Dec 30 '15 at 16:12
  • In C# you can. Probably not in most other non-.NET OO languages. – Martin Maat Dec 30 '15 at 16:21
  • @MartinMaat oh, this was not tagged .NET. I did not see that. In any case that's an implementation detail, not something that would in principle make interfaces incompatible. Interfaces are supposed to be contracts. The syntactic form and rules are just mechanism. – usr Dec 31 '15 at 15:15
1

The conclusion is that one should not change or extend an interface once it has been published and possibly used/implemented by someone. If the need you mention would arise, a new interface would be appropriate rather than changing an existing one.

Martin Maat
  • 714
  • 4
  • 23
0

So, my conclusion is that one should not implement more than one interface. Is that correct?

That seems like the nuclear option.

The real problem here is that FooBar.doStuffY does not implement the contract imposed by the interface. A "slightly different specification" is still different and violates the Liskov Substitution Principle. Had you not done that there would not be a problem.

Maybe you need an internal version of doStuffY that does things differently and decides what to do based on a parameter. That way you can adhere to the interface contract and still allow for deviating behavior for internal usage sites.

usr
  • 168,620
  • 35
  • 240
  • 369
  • So I should blame the guy who wanted to add `doStuffY` to `Foo`, without checking if there could be any name conflicts. He'd better called it `fooDoStuffY` instead, which is quite ugly. – user877329 Dec 30 '15 at 13:24
  • You could say that but it's not clear to me why he implemented Foo anyway if his method is not a proper implementation. He can have a method named doStuffY, no problem. Method names do not have to be unique. It just shouldn't implement the interface. – usr Dec 30 '15 at 13:25
  • Because he thought doStuffY was a descriptive name for the action. Two sender may mean slightly different things when they send the same message, if there is no additional contract. – user877329 Dec 30 '15 at 13:35
  • But why did he implement the interface? – usr Dec 30 '15 at 13:37