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.
Yes, this kind of NIH syndrome is sad and it happens in many other places in the MSFT world.
I once had to hear a 100%-MSFT consultant which I otherwise respect say that the PoEAA have "no real world application"… after having been discussing LINQ to SQL (!)
I always thought that this [i]same [/i]pattern was known by two names:
http://www.codersbarn.com/post/2008/09/22/ASPNET-Email-Strategy-Pattern.aspx
So the problem is one of terminology?
At least in this case, they aren’t just inventing patterns (and practices) — http://serialseb.blogspot.com/2009/01/how-to-fix-microsofts-two-tier-service.html
It’s all about terminology. And as I’ve said before one don’t need to knows the names of all the patterns to use them. This is just the case.
Microsoft just came up with a good solution, which appeared to be a strategy pattern.
I agree with Mike that it’s all about terminology; but that’s exactly why it is important not to re-name existing patterns. One of the points of patterns is to recognize common solutions and establish a common language to describe them between developers; if everyone uses their own brand of pattern-naming, then you are back to step zero, that is, a babel tower of confusion, and you might as well scrap the idea of patterns.
@Mike and @Mathias Yep, and that is exactly what I said at the bottom of the post. Patterns are mostly about expressing a shared lexicon that allows us to communicate effectively with other developers. Very few patterns are used consciously, but most often they are either noticed in implementations we have already built, or refactored to later when we realize that another pattern would have suited us better.
Renaming patterns destroys their value, because it now makes it harder for a Microsoft developer to talk to a Java developer because when people write about the "Provider Model" pattern, they are no longer using an industry standard term.
True, I did paraphrase your last paragraph; I just wanted to clarify where I agreed and disagreed with Mike: it’s certainly important that people write good code following patterns, even if they don’t know what the pattern is, but that’s only half the point of patterns, which as you clearly stated, are first and foremost a language, so knowing patterns names is important.
That being said, I think the real annoying thing is that this comes from Microsoft. It’s fine for a random developer not to know the proper names, but it’s not acceptable for Microsoft to write something on patterns and contribute to the confusion!
Thx for this post. I fully agree!
Agreed, renaming patterns does cause a great deal of confusion. The one thing that I did appreciate from this "Provider Model Pattern" of theirs is how you can leverage it to provide a configurable factory implementation.
Sure, it’s obviously Strategy-based, but it can be used to provide a clean way for configuring instances if you’re not using an IoC container.
Following up to Josh’s comment – it is really a combination of the Factory Pattern and the Strategy Pattern. It’s a Meta-Pattern. lolz 😉
Actually, isn’t the Provider model also referred to as the Abstract Factory design pattern?
Great post, Justin. I’m using the provider model pattern in the current project with my team and we discussed the same thing a few weeks ago 🙂
Provider Model is like someone else mentioned, it is a combination of a factory and strategy. Or you might call it encapsulating a strategy pattern. In the same sense, couldn’t you say that a factory is just a strategy pattern?
Just like MVC pattern isn’t a real pattern, but 3 separate patterns put into one. Provider model is a strategy and factory, and dependency injection / IoC rolled into one.
I normally do not comment… especially about rants because most of the time it is a waste of time… however… in case this time is different… here goes…
While there is a similarity between the Strategy pattern and the Provider patter there are some differences… which you may or may not consider important. At first I thought you were headed down the path of pointing out that the Provider pattern really is just polymorphism and while that is close also… it again is not exactly the same. In either case, this kind of misses the point of why patterns are important… and why I very much agree that changing a pattern’s name does completely go against the main goal of patterns.
Patterns help build understanding quickly. If two people fully understand a pattern… one just has to say that we need to build a component using the [fill in the blank] pattern and no more communication needs to happen… at least as far as HOW the component should be designed. So what patterns provide is a way of quickly communicating a lot of detail information quickly. It expands our vocabulary.
Now as for why I believe the Provider pattern is not a bad pattern to add to our (the developer community’s vocabulary) is because it conveys a lot more details on HOW to construct a component quickly.
If I asked a fellow developer to build a new component using the Strategy pattern we would end up with a fundamentally different component than if they used the Provider pattern. The component would have each public method pluggable independently from the others.
If I asked a developer to build a new component using the Provider pattern it would have the ability to swapped out the implementation of all of the public methods and properties as a unit… plus a way to locate alternate implementations (not that I find this part of the pattern particularly useful).
This may or may not be a significant difference to you but to me it is nice to have that addition in our vocabulary so that I do not have to explain every implementation detail.
To illustrate this a little more. If I have a friend that has 2 vehicles (a Smart car and a pickup truck). If I ask him to bring his vehicle over to my house… he has an option… does he bring the pickup truck or his Smart car? If I am not more explicit and do not tell him why he should bring a particular vehicle then he is free to choose which one he brings. But if I care… I should ask him to bring a specific vehicle.
For me, I care about the difference between the Strategy pattern and the Provider… but I can definitely appreciate the fact that not everyone does.
Great post!
It got me thinking…
One distinction [with a little difference 😉 maybe!] The Provider pattern applies to system-level concerns, i.e. at the API level while the Strategy pattern applies to the class/object level. Extending this … to the language level would be polymorphism.