Freakishly weird interface polymorphism using interface composition

Question

I ended up with something like the following code in a project I'm working on. I thought it was really odd that I was allowed to do it, but now I'm starting wonder what is most likely an architectural gaff on my part led me to this.

My questions to you are:

• What exactly is this called?
• What are some real world uses of this?
• Why would anyone want to do this?

Here are my Interfaces:

namespace ThisAndThat
{
    public interface ICanDoThis
    {
        string Do();
    }

    public interface ICanDoThat
    {
        string Do();
    }

    public interface ICanDoThisAndThat : ICanDoThis, ICanDoThat
    {
        new string Do();
    }
}

Here's my concrete class:

namespace ThisAndThat
{
    public class CanDoThisAndThat : ICanDoThisAndThat
    {
        public string Do()
        {
            return "I Can Do This And That!";
        }

        string ICanDoThis.Do()
        {
            return "I Can Do This!";
        }

        string ICanDoThat.Do()
        {
            return "I Can Do That!";
        }
    }
}

And my passing tests:

using Xunit;

namespace ThisAndThat.Tests
{
    public class ThisAndThatTests
    {
        [Fact]
        public void I_Can_Do_This_And_That()
        {
            ICanDoThisAndThat sut = new CanDoThisAndThat();

            Assert.Equal("I Can Do This And That!", sut.Do());
        }

        [Fact]
        public void I_Can_Do_This()
        {
            ICanDoThis sut = new CanDoThisAndThat();

            Assert.Equal("I Can Do This!", sut.Do());
        }

        [Fact]
        public void I_Can_Do_That()
        {
            ICanDoThat sut = new CanDoThisAndThat();

            Assert.Equal("I Can Do That!", sut.Do());
        }

    }
}

Answer 1

There is absolutely nothing wrong with this code (provided it isn't confusing for your users), and it isn't a pattern with any name that I'm familiar with. CanDoThisAndThat implements two interfaces, so clients can use it in either way.

.NET allows interfaces to be implemented this way -- known as explicit interface implementation.

Explicit interface implementation is useful when:

1. Two interfaces have the same member definition
2. You need to implement an interface but don't want to publicise that a particular member is available to client code that has not declared a reference using the interface type

An example of case 2 from the .NET framework is ICollection.SyncLock. List<T> implements ICollection yet the following code will not compile because the member has intentionally been 'hidden' as the designers of the BCL no longer advocate locking collections in this way:

List<object> list = new List<object>();

lock (list.SyncRoot) // compiler fails here
{
    // ...
}

Any legacy code of this format will still work, because the reference is of type ICollection explicitly:

ICollection list = new List<object>();

lock (list.SyncRoot) // no problem
{
    // ...
}

Answer 2

Each type has an interface mapping (which can be retrieved with Type.GetInterfaceMap if you want to look at it with reflection). This basically says, "When method X on interface Y is invoked, this method Z is the one to call." Note that even though it's not supported in C#, it's possible for the mapping target method to have a different name from the interface method name! (VB explicitly supports this, I believe.)

In your case, you have three methods and each of the three methods corresponds to a method in one of the interfaces involved.

When the compiler issues a call to a virtual method via an interface, the IL generated says something like "call IFoo.Bar on this object" - and IFoo.Bar is then resolved using the interface map.

You may sometimes need to use it if either you have signatures which differ only in return type, or if you're implementing two heterogeneous interfaces which happen to have the same method names but should do different things. Wherever you can avoid it though, do! It makes for very confusing code.