Before I answer that question, I wish to remind/inform everyone that this is part of a long series of posts. You can access the list of other posts in this series at the bottom of the post. It might not be a bad idea to review through them before (or after) you read this post. The proxy pattern doesn’t really depend on the knowledge of any of the other patterns, so you can wait until after you’re done here if you’d like. If you’ve already read all the other posts in the series then you deserve some brownie points! Too bad I don’t really have any to give away.
Returning to the question of why we would bother to use a proxy, we can give a few different scenarios where the proxy can come in handy: delaying instantiation of a large object, accessing a remote object, and access control.
Before we get into each of those situations, we’ll look at an example of a proxy with no purpose, just so you get the gist of what a proxy is. First we need to create a class –
CarList – and then we’ll just make the proxy class that wraps around it.
I’m sure everyone reading this has some bit of imagination, so let’s pretend that
CarList has 10 times as many methods and most of them are very large and complicated. I know this circumstance might be a bit extreme, but I’m just exaggerating a bit to make a point. The point is that we have a large object that would use up quite a few CPU cycles just to instantiate it. Wouldn’t it make sense to put off that instantiation until we’re sure it’ll be used? Well, that’s the point of the Virtual Proxy. Someone can instantiate a proxy and the normal large object won’t be instantiated until a method is called that requires its creation. Let’s convert our old useless proxy to a virtual proxy.
Of course this may not necessarily be the best method of delaying the initialization of a large object. Let’s imagine (again) that
CarList didn’t have countless complex methods, but just the data that it contains is large, such as an entire database of the make and model of every single commercially-produced vehicle in existence. In this case, we can just create a method that initiates all of that data, but only call that method when we are in need of that data. I’m not saying to put down the power of the proxy pattern, but more so to help you be a better programmer by teaching you that a proxy isn’t the answer to all problems.
This time our
CarListProxy isn’t implementing the interface of an object, but instead just pulling information from the fictional web service on www.WeSeriouslyListEverySingleVehicleModelEver.com.
In order to truly control access, we have to make sure that there is no way to access the original object in any way except through the proxy, so we’ll close it all up in a self-invoking anonymous function, but attach the proxy as a property to
window in order to give access to it from the outside world.
And there you have it: all three flavors of the proxy pattern with examples. Personally I don’t see a whole lot of circumstances where a proxy will be all that useful, except maybe as a facade for web services, especially with the growing popularity of the use of web services. I hope that you all can find a reason to use it because knowledge is power, but only if it can be applied.