Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

4 Answers 4

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.

share|improve this answer
2  
Is it just me, or does this sound like a terrible idea? –  Kevin Peno Apr 20 '11 at 21:37
1  
@Kevin, how so? Sometimes the interface is out of your control, and you have to use it. Mitigating the damage of an overbearing interface seems reasonable. –  Chris Pitman Apr 21 '11 at 2:19
    
+1 for pointing out that many times the real world gets in the way of the right way of doing things. @Kevin yes it's a terrible idea but sometimes you don't have a choice and have to work with the slop - better to hide it away and make a facade of doing things properly when you can't really do it properly. –  Wayne M Apr 21 '11 at 12:22
    
@Wayne, I understand your reasoning for wanting/using such a system. Hell, I'd probably use it to in exactly the case you state. I guess my short comment was really just pointing out that this is improper, so why allow it in the language. –  Kevin Peno Apr 21 '11 at 14:59
    
@Kevin Here is an example from memory. You are implementing "ConcurrentDictionary". Your class has to support being read like an IDictionary, so it can be used in classes that know how to read from IDictionary. So, you add these new functions that allow you to write safely like AddOrUpdate. To discourage the use of the non-threadsafe writing members you explicitly implement them. –  Patrick M Mar 24 at 1:25

Sorry about replying almost a year too late :P

The most useful application I found is with implementing factories. In many cases, it is useful to create classes that are mutable inside the factory but immutable to external classes. This can be easily implemented in Java using inner classes, by making the fields and their setters private and only exposing the getters as public members. However in C#, I had to use explicit interfaces to achieve the same thing. I'll explain further:

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 means that private fields and methods in the inner class can still be accessed by the factory to modify their values. But external classes will not be able to access these fields except through their public getters.

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, not fields).

Example:

public class Factory
{
    // factory method to create a hard-coded Mazda Tribute car.
    public static Car CreateCar()
    {
        Car car = new Car();

        // the Factory class can modify the model because it has access to
        // the private ICarSetters interface
        ((ICarSetters)car).model = "Mazda Tribute";

        return car;
    }

    // define a private interface containing the setters.
    private interface ICarSetters
    {
        // define the setter in the private interface
        string model { set; }
    }

    // This is the inner class. It has a member "model" that should not be modified
    // but clients, but should be modified by the factory.
    public class Car: ICarSetters
    {
        // explicitly implement the setter
        string ICarSetters.model { set; }

        // create a public getter
        public string model { get; }
    }
}

class Client
{
    public Client()
    {
        Factory.Car car = Factory.CreateCar();

        // can only read model because only the getter is public
        // and ICarSetters is private to Factory
        string model = car.model;
    }
}

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

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.