Explicit interface implementaion with second implementation

Question

I was tracking down a bug and I found this in the Avalon Dock 2.0 source code:

 public abstract class LayoutContent : LayoutElement, /* ... */, ILayoutPreviousContainer
 {
    // ...
    [XmlIgnore]
    string ILayoutPreviousContainer.PreviousContainerId
    {
        get;
        set;
    }

    protected string PreviousContainerId
    {
        get { return ((ILayoutPreviousContainer)this).PreviousContainerId; }
        set { ((ILayoutPreviousContainer)this).PreviousContainerId = value; }
    }
}

ILayoutPreviousContainer has a member string PreviousContainerId { get; set; }.

What does this pattern accomplish? I understand that you could not get/set the PreviousContainerId from outside the inheritance subtree unless you first cast the LayoutContent to an ILayoutPreviousContainer. But I don't understand why you would want this.

Upon doing research about this pattern, I found this SO post which confused me some more. By implementing it this way, it is seemingly similar to having just a virtual property that would be implemented in a convoluted way:

public class SpecificLayoutContent : LayoutContent, ILayoutPreviousContainer
{
     // override LayoutContent.PreviousContainerId since it casts 'this' to an ILayoutPreviousContainer
     // which will then call this property
     string ILayoutPreviousContainer.PreviousContainerId{ /* ... */ }
}

Am I missing something?

Jeppe Stig Nielsen · Answer 1 · 2014-06-04T20:54:16.847

A protected property cannot implement an interface property, implicitly or explicitly. So if you want easy direct access from this class and derived classes, you want one protected property and another "hidden" property which explicitly implements the interface.

Looking at your example, one could consider switching roles of the two properties, such that the protected one was an auto-property, and interface-implementing one was referring to the auto-property (and not the other way around).

What alternative do you see? One could stick to a single property if that was made public (so implementing implicitly), but in that case the property would be exposed much more which is apparently not desired.

Yes, I was thinking a single public interface. If `ILayoutPreviousContainer` was `public` instead of `internal`, you already would have a `public` property, but since it is `internal`, the explicit implementation of it also acts like it is `internal` — clcto, Jun 04 '14 at 21:02

score 1 · Accepted Answer · answered Jun 04 '14 at 20:50

1

ILayoutPreviousContainer seems to be an internal interface. So as far as outside users of SpecificLayoutControl are concerned, the interface doesn't exist, and there is just the PreviousContainerId property defined on the class.

The usual rules apply for whether that should be protected or public. I won't expand on that, since it doesn't seem like that's what your question is about.

The class's authors have decided that the property should be protected. However, if it is protected, it cannot implement the interface's property, and although external users don't see that interface, internally that interface is required elsewhere. So, they implemented it like this, where one property merely forwards to the other.

answered Jun 04 '14 at 20:50

The `internal` part is what I was missing. So this implementation keeps the access to `PreviousContainerId` `internal` as well, instead of `public` which would be the case with a single public property. – clcto Jun 04 '14 at 21:06
The `internal` scope is not clear from the code and doesn't seem needed or relevant. The whole setup would work with a `public` interface in the same way. – H H Jun 04 '14 at 21:30
@HenkHolterman with a `public` interface, there is more visibility to the property `PreviousContainerId`, as you could cast any `LayoutContent` to a `ILayoutPreviousContainer` and then have access to the property. – clcto Jun 04 '14 at 21:37
@clcto - yes, but none of that is crucial to this question. – H H Jun 04 '14 at 21:40
@HenkHolterman It is the reason for doing this, at least in this scenario. Or at least it satisfies my curiosity about why this was there. – clcto Jun 04 '14 at 21:47
@HenkHolterman I read the question as "why make it so complicated if all the world can access the property anyway?", and for that question, showing that all the world cannot access the property anyway is relevant. – Jun 05 '14 at 05:05
It is complicated, to meet a very specific set of accessibility requirements. But while the `internal` part may have been a motivation, it is not as essential as the `protected` modifier. – H H Jun 05 '14 at 07:02
@HenkHolterman I understand that technically, it works the same way with a `public` interface as an `internal` one, but the result is different: with a `public` interface, you merely hide the property. With an `internal` one, you make it inaccessible. If the OP asked how it works, then sure, you're right, the accessibility of the interface is irrelevant, but that's not what this question is about. The OP asked *why* you might want it, and the reasons why you might want to hide something are different from why you might want to make it inaccessible. – Jun 05 '14 at 07:17

Explicit interface implementaion with second implementation

2 Answers2