Lecture thumbnail 0:01 / 3:12 In this module, we’re going to take a look at the proxy design pattern.
And the proxy is all about providing an interface for accessing a particular resource by essentially
replicating that interface.
So let’s talk about the motivation for using the proxy or at least one of the motivations.
So let’s suppose that you are making a call to Foo Bar.
So there is some assumption in this regard.
You’re for example, you’re assuming that the object foo is actually available in the process where
you’re running things and the foo is in the same process as the bar invocation.
Now that might not necessarily be the case because at some point later on, maybe not now, but maybe
later, you want to put all the foo related operations into a separate process.
So whenever somebody calls Foo Bar here, you actually want to take all the arguments to that bar.
You want to marshal them over the wire and actually execute everything that’s related to this object
on a separate machine.
In fact, the net framework allows you to do this.
We have certain base classes like Martial by ref object, which allows you to do precisely this.
So the big question is, can we actually avoid changing our code if we want to do this?
So this is where the proxy design pattern comes to the rescue.
And the idea is very simple.
So you have an object which is the proxy object, which has exactly the same interface as what you’ve
been used to, what you’ve already been working with.
Maybe, but it provides entirely different behavior.
So, for example, in the case that we are describing here, the proxy, the kind of proxy that you
would provide in place of foo, maybe you would have some sort of remote foo implementing the I foo
interface.
This is what’s called a communication proxy.
So it’s something that kind of substitutes a different execution model where the invocations aren’t
actually local, they only appear to be local.
But when you actually call Foo Bar, what bar does is it takes all the arguments, puts them into serializable
structures, and then marshals it off to wherever for example.
And there are lots of other different kinds of proxies.
For example, you can have logging proxies where on every invocation, in addition to actually calling
the underlying object, you also perform logging.
You can have virtual proxies, you can have guarding proxies.
So a guarding proxy is something where you check access control.
Whenever somebody calls a method, you check whether they are in fact allowed to call this kind of method.
And there are lots of many other different varieties.
So the proxy design pattern is all about providing a class which functions as an interface to a particular
resource.
So that resource, it may be remote, it may be expensive to construct, it may require logging or some
other additional functionality.
So once again, this is the idea of providing additional functionality on the object.
But the nature of that functionality doesn’t have to be intrinsic to the object itself.
So, for example, you might want to have a protection proxy over all your objects and have authentication
rules so that you specify some sort of custom security policy where some people are only allowed to
touch certain parts of the API, but certainly not all the range of APIs available.
Stop Play Play Play Play Play Play Play Play Start Play Play information alert