Using extension methods to decrease the surface area of a C# interface

An interface defines a contract to be implemented by one or more classes.  One of the keys to a well-designed interface is defining a very specific range of functionality. The profile of the interface should be limited to a single purpose & should have the minimum methods required to implement this functionality.  Keeping the interface tight will keep those implementing the interface from getting lazy & not implementing it properly.  I've seen too many overly broad interfaces that aren't fully implemented by developers.  Instead, they just throw a NotImplementedException for the method they didn't implement.

One way to help with this issue, is by using extension methods to move overloaded method definitions outside of the interface.

Consider the following example:

   1:      public interface IFileTransfer
   2:      {
   3:          void SendFile(Stream stream, Uri destination);
   4:      }
   5:   
   6:      public static class IFileTransferExtension
   7:      {
   8:          public static void SendFile(this IFileTransfer transfer, 
   9:              string Filename, Uri destination)
  10:          {
  11:              using (var fs = File.OpenRead(Filename))
  12:              {
  13:                  transfer.SendFile(fs, destination);
  14:              }
  15:          }
  16:      }
  17:   
  18:      public static class TestIFileTransfer
  19:      {
  20:          static void Main()
  21:          {
  22:              IFileTransfer transfer = new FTPFileTransfer("user", "pass");
  23:              transfer.SendFile(filename, new Uri("ftp://ftp.test.com"));
  24:          }
  25:      }

In this example, you may have a number of overloads that uses different mechanisms for specifying the source file. The great part is, you don't need to implement these methods on each of your derived classes.  This gives you a better interface and better code reuse.

4 Comments

  • Any reason why you have gone against the convention and named a class similar to an interface?

    Arun

  • I do this all the time. Works great. Convention violation is OK because we are faking our own language extension where we make believe interfaces can actually contain methods (dream a little dream), and you're doing it with a name that you're likely never to experience a collision with - and rarely even see.

  • I usually name my extension method class after the class or interface I'm extending. While this violates the "I" is for interface convention, it makes the relationships very clear which is probably more important.

  • I was trying to figure out how you would ensure someone actually used your extension methods...then of course I realised that it is just in the same namespace they will import, so I assume it will work if you say:

    using mynamespace;

    However if client code absolutely accessed the class as in:
    mynamespace.IFileTransfer
    Then the extension methods would not be pullin in right? Still - a nice idea.

Comments have been disabled for this content.