In Rob Howard’s article, http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspnet/html/asp02182004.asp,
he describes the “Provider” pattern as coined by Microsoft.  I like the pattern,
and it seems similar to the Strategy pattern as put forth GoF.

I love the benefits:  the ability to control what provider is used by a
configuration item.  Microsoft seems to have coined the term “Provider”, so I
guess it’s their definition, but at the lowest level it is an abstract class
that defines the contract, or API.  Then a configuration item controls which of
the abstract class’s implementation in invoked.  For example, I could have a
class that needs data.  I think we can all imagine different classes that allow
access to different data sources.  All the different data sources would have a
class that inherited from the abstract provider class.  My client class would
get the configuration item that contained the assembly and type of the provider
implementation and instantiate it through reflection.  The reference would be of
the abstract base class, so no matter which provider is configured, The client
will instantiate the appropriate one at runtime and access it through the
methods defined in the abstract class.

Personally, I would choose an interface first.  I know they are immutable,
but is that an issue?  Using an abstract class eliminates the possibility of
having a base class for the provider elsewhere, so it seems to me that this is
an unnecessary constraint.  If the contract of the base class needs to provider
base functionality, then an abstract class makes sense, but as long as it is
just an API contract, I would favor an interface.

I feel that the “Provider” pattern should specify the general concept and not
specify inheritance vs. interface.  I would consider either to be the Provider
pattern depending on the application of the pattern.