What are good reasons to use explicit interface implementation for the sole purpose of hiding members?

Question

During one of my studies into the intricacies of C#, I came across an interesting passage concerning explicit interface implementation.

While this syntax is quite helpful when you need to resolve name clashes, you can use explicit interface implementation simply to hide more "advanced" members from the object level.

The difference between allowing the use of object.method() or requiring the casting of ((Interface)object).method() seems like mean-spirited obfuscation to my inexperienced eyes. The text noted that this will hide the method from Intellisense at the object level, but why would you want to do that if it was not necessary to avoid name conflicts?

Answer 1

Imagine a situation where an interface forces a class to implement methods which do not actually make sense as part of the class. This can often happen when interfaces are particularly large and violate the Interface Segregation Principle.

This class needs to implement the interface, but instead of poulte its highly visible public interface with methods that do not make sense, you can explicitly implement those methods which you do not want to be obviously available. The highly visible public interface of the class is how you want the class to be used, and the explicit implementation is there when the class is accessed through the interface.

Answer 2

Sorry about replying almost a year too late :P

I recently used Java nested classes in an interesting way, and wanted to see if it can be done in C#.

In Java, the inner class AND the outer class can access private members of each other, which makes total sense as the classes are very closely related. They are in the same code file and are probably developed by the same developer. This allows the creation of inner classes that are immutable to external classes but can be modified by the outer class.

However, in C#, outer classes cannot access private members of inner classes so that concept is not directly applicable. I used an explicit interface as a workaround by defining a private interface in the outer class and explicitly implementing it in the inner class. This way, only the outer class can access the methods in this interface the same way it is done in Java (but they have to be methods, no fields).

Example:

public class Class1
{
    public Class1()
    {
        Class2 c2 = new Class2();

        // can modify field2
        ((I2)c2).field2 = 2;
    }

    private interface I2
    {
        // define the setter in the private interface
        int field2 { set; }
    }

    public class Class2 : I2
    {
        // explicitly implement the setter
        int I2.field2 { set; }

        // create a public getter
        public int field2 { get; }
    }
}

class Class3
{
    public Class3()
    {
        Class1.Class2 c2 = new Class1.Class2();

        // can only read field2 because only the getter is public
        // and I2 is private to Class1
        int val = c2.field2;
    }
}

That is what I would use explicit interfaces for. Any other suggestions?

Answer 3

Perhaps if you had functionality that was useful to the users, but only if you really know what you're doing (enough to have read the documentation to learn about the function) but that is likely to break things if you don't.

Why you'd do that rather than providing, say a second "advanced features interface" I don't know.

Answer 4

Code is generally read more than it is written and I only use Intellisense to write code quickly. I wouldn't write code a particular way just to make Intellisense nicer.

I don't particularly see how

((Interface)object).method() is any more readable than object.method().

If I had a lot of methods on a particular object, I might question whether or not its a god object and should actually be broken into multiple simpler objects.