Code of Contention: Explicit Interface Implementation
Wednesday, March 04, 2009 9:15 PM
Interfaces are like vegetables, you know you're supposed to eat/use them more, but yaaaaaaaaaa know, life just gets in the way sometimes right? Read on for a cool idea to help your consumers use your interfaces better.
I was watching an interesting PDC 08 vid this week about Interfaces. It evangelizes using interfaces more and more and more and.....you get the picture eh? Microsoft basically wants developers to use interfaces for EVERYTHING! Weeeeeeeell, real life sometimes happens and you create/use/share classes around instead right? Those classes will undoubtedly implement interfaces at some point in your career right? If you do that, then those interfaces will, uh,......hhhhmmmm "clutter" up all the methods when you goto use intellisense, is there a better way?
I hestitate to say I have a "better" way, but I do have something cool to show you. Have you heard of Explicit Interface Implementation? The premise is implementing classes can get away with implementing an interface thereby satisfying your requirements and the compiler but not polluting the intellisense and confusing your class consumers.
What do I mean? Can you imagine:
- implementing an interface called IHockey
- IHockey has a method called Shoot()
- your Canadiens class implements IHockey and therefore you code up a Shoot()
- BUT when you goto use your Canadiens class, Shoot() doesn't show up in Intellisense
Wait a sec, I thought if we whipped up a Shoot() then it's part of Canadiens which by definition implements IHockey and THEREFORE SHOULD, no, HAS to have the Shoot()!!!!!!!!!!! What is going on? Is Java getting more mindshare over C#? WTF? No, no, no, hold on, this is all part of Explicit Interface Implementation. Watch in the following example.
public class Canadiens : IHockey
Console.WriteLine( "He shoots, HE SCOOOOOOORES!!!!!!!!!!!" );
public int GetScore()
Random rand = new Random();
return rand.Next( 10 );
public class TestInterfaces
static void Main( string args )
Canadiens habs = new Canadiens();
int score = habs.GetScore();
Console.WriteLine( "Score = " + score );
IHockey hockeyTeam = habs;
You see how IHockey has two methods declared right, Shoot() and GetScore(). With me so far?
Ok, now look at Canadiens class, the one implementing IHockey, notice how GetScore and Shoot methods are declared. Notice how they're different? The Shoot method is explicitly prefixed with the IHockey interface, where as the GetScore method is just like any other regular method declaration. So far so good?
So what's the big deal you ask? Good question. Watch what happens (next diag) when you goto use the habs object by calling up the Intellisense, you see how you get all the methods and properties and GetScore is there? In other words, some of the interface methods are "polluting" your class and potentially confusing your class consumers. Yes, you might want this but sometimes you don't (that's the cool part of this post :>). Also notice what's NOT there, the Shoot method.
Shoot is MIA? Did it score? Ok, bad joke, small hockey humour. :>
You're seeing the magic part about Explicit Interface Implementation. Because you prefixed the method declaration with IHockey, although it's part of the Canadiens class, and the CLR/compiler/your boss/etc are all happy, you're forcing your class consumer (TestInterfaces class) to use IHockey as the object to call the Shoot method. That's the ONLY way to get to the Shoot method (next diag).
Of course you'll also see the GetScore method in there, it is part of the IHockey interface as well, but the Shoot method isn't polluting the intellisense of your Canadiens class. I thought this was a cool way to "hide" a method while still satisfying the compiler.
Grab a coffee and get coding! :>
MSDN: Explicit Interface Implementation (C# Programming Guide)
MSDN : Explicit Interface Implementation Tutorial