Anson talks about what some work we've done on Implement Interface.

When I code today, I always use “Explicit Implementation” for interfaces.  My thinking is that the interface represents a contract with an “external”.  If I happen to want a similar behavior to call directly on the class, I don't necessarily want to sign up for that contract. 

So, I start by creating an explicit implementation.  If I decide I need that functionality somewhere else, I refactor to make it accessible directly.  For example, Extract Method on the existing method, and call the extract method directly.

Another pattern I'm experimenting with is using Whidbey's partial types in concert with explicit interface implementation.  I end up with something like:

     using System;

 

    partial struct Angle : IComparable<Angle>

    {

        int IComparable<Angle>.CompareTo(Angle other)

        {

            return this._value - other._value;

        }

 

        bool IComparable<Angle>.Equals(Angle other)

        {

            return this._value == other._value;

        }

 

    }

 

    partial struct Angle

    {

        readonly double _value;

 

        public Angle(double value) { this._value = value; }

    }

It allows me to call out the part of the class that is responsible for implementing the interface vs. the part that does other stuff.  If the class starts to become unwieldy, I can split into two classes: one for satisfying the public contract (the interface) and one for encapsulating the inner functionality.