This may not make much sense until you get a little better context; at least that’s usually the way I feel when I’m first told how something works. So, how about we give a bit more information and context? First off, this pattern is designed to be used within existing code. Our existing code utilizes some object or function, but we want to replace it with a different one. The problem is that the new object/function uses a different interface than the one we’re currently using. Instead of changing the code in every spot that is using the current object, we bring the adapter into play.
The adapter takes the new object that we’re going to use and either wraps it, or just mediates to it, depending on how the object is used, to match it to the interface established by the old object. In the case of an object that always get instantiated with the
new operator, the adapter will wrap it by containing an instance of the object within itself and passing function calls on to it. If the object is “static” in the sense that there is only one instance of it, then it will not be wrapped.
There are plenty of examples I could give to show how and when to use the Adapter. I believe the most common examples come when a project is utilizing a framework or library: jQuery for instance. The problem comes later when, for whatever reason, there is a decision to use a different library (e.g. YUI). In a large application, there is absolutely no way to go through all of the code and change every call that has to do with jQuery into YUI calls. You’d have to create an adapter, which in this case would be quite difficult, but would be better than the former idea.
When I said it was possible, what I really meant was that it will happen right now. First let’s show the little
LoggerFactory, which will allow us to more easily change the logger we’re using.
Notice how all it does is send us the console object when we call
getLogger. We’re going to pretend for the sake of this exercise that the console only has one method –
Note we’re using jQuery to accomplish the AJAX request in order to save time and hide the clutter involved with cross-browser AJAX, which has nothing to do with the adapter pattern.
Now all we need to do is create an adapter and change the factory to return the adapter instead of console.
The only change we made to existing code was to one line in the factory and suddenly our entire application is now using an entirely different logger.
This logger is a very simple example where there is only one function and that function maps pretty much straight to the old function without any difficulty. There are many instances where this isn’t the case. You may run into a problem where the functions map together very differently by using entirely different arguments, which you might have to create yourself if the old interface didn’t include them. In some cases you may just drop some of the arguments that are sent because the new object doesn’t use them at all. You never know. If it is too difficult to map the interfaces of the two objects, then you may need to try something else, which I hope doesn’t include going through thousands of lines of code to change every usage of the original object.