Using C# explicit interface implementation for hiding…

One thing that surprised me the most about the C# was the fact that it does not support multiple inheritances (which I knew from the C++). How can we deal with that? Of course, we use interfaces, since one class can implement more than one. But quickly we come to the very common problem:

 


class Test : ITestOne, ITestTwo
{
    void Print() // ERROR
    {
        Console.WriteLine($"I belong to the {nameof(ITestOne)} inteface!");
    }

    void Print() // ERROR
    {
        Console.WriteLine($"I belong to the {nameof(ITestTwo)} inteface!");
    }
}

interface ITestOne
{
    void Print();
}

interface ITestTwo
{
    void Print();
}

 

Why is that confusing? Well, in a perfect world compilers would just read both strings and decide (like humans do) which method stands for the proper interface. But it’s not that easy and we need to help in order to make it work. So, what is the solution? Since Test has to implement both of the interfaces we need to implement their methods explicitly. The example code is given below:

 


class Test : ITestOne, ITestTwo
{
    void ITestOne.Print() // Ok
    {
        Console.WriteLine($"I belong to the {nameof(ITestOne)} inteface!");
    }

    void ITestTwo.Print() // Ok
    {
        Console.WriteLine($"I belong to the {nameof(ITestTwo)} inteface!");
    }
}

interface ITestOne
{
    void Print();
}

interface ITestTwo
{
    void Print();
}

 

That code does not confuse the compiler anymore since we disambiguated methods by telling directly which implementation belongs to the proper interface. That’s the most common usage of the explicit implementations. But, there’s one more that might interest you in some cases…

 

Hiding interface’s members

As you probably all know, declaring methods/properties in the interface does not allow us to implement that as non-public. That seems logical since interface defines set of features that objects need to have. But there are some scenarios where having that kind of possibility would be handy. Let’s take a look at the code below:

 


public interface ISoftDeletable
{
    bool IsActive { get; }
    void Delete();
}

public abstract class InternalEntity : IInternalEntity<int>, ISoftDeletable, IAuditable
{
    [Key]
    public int Id { get; set; }

    public DateTime CreatedDate { get; set; }

    public DateTime UpdatedDate { get; set; }

    public bool IsActive { get; private set; }

    protected InternalEntity()
    {
        this.IsActive = true;
    }

    void ISoftDeletable.Delete()
    {
        this.IsActive = false;
    }
}

 

That’s the listing from my project which I was doing back in the February for the Polish programming competition. What’s the point? Well, in this case, I defined an interface for the soft delete operation but I implemented its method explicitly. Why?

 

  • I wanted to keep it private (explicit method cannot be public) and invoke the Delete method through the repository class, so the flow will be more controlled.
  • I wanted to be sure that every class which will implement ISoftDeletable interface will also have the implementation of the Delete method (I just don’t trust my memory).

 

Explicit implementation gave me both – (kinda) private and obligatory methods inside the class. Now, it worth to write down some comment about invoking that kind of methods. Here’s the code from the repository:

 


public void Delete(TEntity entity)
{
    var softDeletableEntity = entity as ISoftDeletable;

    if(softDeletableEntity == null)
        throw new NotSupportedException("Entity must implement ISoftDeletable interface");

    softDeletableEntity.Delete();
}

 

As long as we won’t cast the class to the ISoftDeletable type, the Delete method won’t be visible. After using the as keyword we can access that like any other class member. Of course, there are any usages of the explicit interface implementation like backward compatibility but this one seemed to me to be the most useful.

 

You may also like...