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
add comment

4 Answers

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
1  
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
show 1 more comment

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?

share|improve this answer
add comment

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
add comment

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
add comment

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.