Worried you’ll miss us?
Subscribe to get our articles and updates in your inbox.
This is going to be a bit of a rant post, and it is probably a bit pedantic, but I come across this one pretty regularly and so I just felt the need to post something about it.
Check out this description of the “Provider Model” design pattern on MSDN:
The pattern itself is exceedingly simple and is given the name "provider" since it provides the functionality for an API. Defined, a provider is simply a contract between an API and the Business Logic/Data Abstraction Layer. The provider is the implementation of the API separate from the API itself. For example, the new Whidbey Membership feature has a static method called Membership.ValidateUser(). The Membership class itself contains no business logic; instead it simply forwards this call to the configured provider. It is the responsibility of the provider class to contain the implementation for that method, calling whatever Business Logic Layer (BLL) or Data Access Layer (DAL) is necessary.
Okay, so they describe it as defining a contract between an API and business logic or data access. So we create an implementation of a particular provider and then implement the logic for the abstract methods that the provider implements.
Something like this:
Sweet. What a great idea, we have this abstract API and all we have to do is create a concrete implementation of it and then the calling code can use our implementation. The only problem here is that I could rip the alternator out of my car and call it an electricityanator and explain to everyone that it creates electrical power from the mechanical output of the engine, but anyone I show it to is going to immediately know that it is an alternator.
If you’re still not sure where I am going with this, then let me pull another quote from somewhere else, this time from a wikipedia page:
The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application. The strategy pattern is intended to provide a means to define a family of algorithms, encapsulate each one as an object, and make them interchangeable. The strategy pattern lets the algorithms vary independently from clients that use them.
Gee, that sure does sound a whole lot like the “Provider Model” pattern. Now I know that the strategy pattern explicitly talks about using interfaces, and the provider model uses abstract classes, but these are the same patterns people! They each have an interface which is then implemented by any number of providers that can be swapped out.
Patterns are not something that we build our applications toward, they are recurring solutions to common problems, and so therefore they are very often observed after they have already been implemented in an application. We must strive to describe what we have in terms of the patterns that already exist. Because if we don’t even take the time to look around and reuse patterns that are already in existence, then we will end up ruining the whole point of having patterns, which is to allow software engineers to communicate design without having to specify everything in excruciating detail.
Sorry, I am done ranting for the day.
Loved the article? Hated it? Didn’t even read it?
We’d love to hear from you.