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());
        }

    }
}

score 5 · Accepted Answer · answered Feb 13 '09 at 07:21

5

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:

Two interfaces have the same member definition
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
{
    // ...
}

answered Feb 13 '09 at 07:21

Drew Noakes

300,895
165
679
742

Thanks, giving you the answer because you provided the exact name of the what's going on. – Scott Muc Feb 14 '09 at 20:01
Downvoted as you've got a lot of errors in your answer. First, the class `CanDoThisAndThat` implements THREE interfaces, not two. `ICanDothisAndThat` states that, when implememnted, you must also implement the two other interfaces. Also, SyncRoot is not explicitly defined by implemenations to hide it to discourage use, its done usually to keep rarely used members out of site, or if the fact that an interface is implemented sholdn't matter. Look at http://msdn.microsoft.com/en-us/library/system.collections.icollection.syncroot.aspx and http://msdn.microsoft.com/en-us/library/bb356596.aspx. – Andy Jan 28 '12 at 13:52
No where in that documentation does it say you shouldn't use SyncLock, nor are they marked as Obsolete, which is what's really done when something should no longer be used. – Andy Jan 28 '12 at 13:53
1

@Andy the SyncRoot property has been regarded as a questionable design for some time by senior Microsoft engineers. Take a look at [this post](http://blogs.msdn.com/b/brada/archive/2003/09/28/50391.aspx) by Brad Abrams, in which he explicitly says "Rest assured we will not make the same mistake as we build the generic versions of these collections." – Rich Tebb Jan 28 '12 at 17:34
@RichTebb, not exactly a solid condemnation either. That blog is from 2003, and yet SyncRoot remains to this day and has not been obsoleted. Regardless, the reason for making it an explicit was not to hide it. It was done that way in 1.1, which is the oldest framework documentation I could find. I can only assume it was also explicitly implmented in 1.0 as well, more likely to allow us a way to provide our own implmentation of SyncRoot. Stating it was done to discourage use is just wrong. http://msdn.microsoft.com/en-us/library/system.collections.collectionbase_members(v=vs.71).aspx – Andy Jan 28 '12 at 18:15
@Andy, it's generally a bad idea to lock on public objects (which `SyncRoot` promotes) as you have no control over how other code may use the same object for locking, and hence it becomes harder (impossible?) to rule out deadlocks for users of your code. – Drew Noakes Jan 29 '12 at 22:13
@DrewNoakes I understand that. The fact is that SyncRoot was NOT made an explicit interface implementation to discourage its use, nor has MS obsoleted it (which I think they should). My problem with the answer remains; explicit interface implementations are not meant to discourage use. – Andy Jan 30 '12 at 01:19
Explicit interface implementation is often useful and appropriate where an interface will ask a question to which all instances of a type are required to give the same answer. For example, although `IList` implements property `IsReadOnly`, and `ReadOnlyCollection` implements `IList`, there's no reason to call the `IsReadOnly` method on something known to be a `ReadOnlyCollection`. SyncRoot is a bit of an odd bird, though, since if a `List` may be encapsulated within a `ReadOnlyCollection` which could be cast to `ICollection` by code that uses the `SyncRoot` of... – supercat Feb 20 '15 at 23:03
...that `ICollection`, then any code which wants to synchronize on the `List` should cast it to `ICollection` and synchronize on its `SyncRoot` property, but outside of that particular case, code shouldn't use `SyncRoot` to synchronize to a list. – supercat Feb 20 '15 at 23:04

Jon Skeet · Answer 2 · 2009-02-13T07:39:38.273

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.

Freakishly weird interface polymorphism using interface composition

2 Answers2