Search
Sunday, December 09, 2018 ..:: Home ::.. Register  Login
   Calendar  
     
  
   Search  
     
  
   Blogroll  
     
  
   Disclosure  
All blog entries are the opinions of the author and do not necessarily reflect the opinions of their employer. All the code presented is for explanation and demonstration purposes only. Any damages incurred to your site and/or data are not the responsibility of the author. Every effort is taken to ensure the code properly compiles, however sometimes there are some hiccups and you might be required to do your own debugging.
     
  
   TechTidBits (Blog)  

Code of Contention: Explicit Interface Implementation

Mar 4

Written by:
Wednesday, March 04, 2009 9:15 PM  RssIcon

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.

namespace PCHenry.TestInterfaces
  {
    interface IHockey
    {
      void Shoot();
      int GetScore();
    }

    public class Canadiens : IHockey
    {
      void IHockey.Shoot()
      {
        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;
        hockeyTeam.Shoot();

        Console.ReadLine();
      }
    }
  }

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.

All class methods show up including non explicit interface methods

 

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).

Explicit interface methods only show up

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! :>

  

 

Resources:

MSDN: Explicit Interface Implementation (C# Programming Guide)

MSDN : Explicit Interface Implementation Tutorial

Tags:
Categories:
Location: Blogs Parent Separator TechTidBits

Your name:
Gravatar Preview
Your email:
(Optional) Email used only to show Gravatar.
Your website:
Title:
Comment:
Add Comment   Cancel 
     
  
Copyright 1999-2012 by PCHenry.com   Terms Of Use  Privacy Statement