Proxy will lazily call a method from the object
Apart from that, Virtual Proxy will lazily create an object (at the first usage)
Other than that, Protection Proxy will authorize the privilege before calling the method from the real object, it acts like the before callback on Rails Controller
“Is this operation authorized?” asks the protection proxy.
“Does the subject actually live on this other machine?” asks the remote proxy.
“Have I actually created the subject yet?” asks the virtual proxy.
In short, the proxy controls access to the subject.
We hand to the client an object that looks and acts like the object the client expected, but is actually an imposter. As the figure below, the proxy by the GoF, has a reference to the real object, the subject, hidden inside. Whenever the client code calls a method on the proxy, the proxy simply forwards the request to the real object.
Let’s take our generic, do-nothing BankAccountProxy and turn it into a protection proxy, a proxy that controls access to the subject. To do so, we need simply add a check at the start of each method. Each operation on the account is protected by a call to the check_access method. The check_access method does what its name implies: It makes sure that the current user is allowed to access the account.
Finally, we can use a proxy to delay creating expensive objects until we really need them.
It pretends to be the real object, but it does not even have a reference to the real object until the client code calls a method. Only when the client actually calls a method does the virtual proxy scurry off and create or otherwise get access to the real object.
Like the other two flavours of proxies, the virtual proxy provides us with a good separation of concerns: The real BankAccount object deals with deposits and withdrawals, while the VirtualAccountProxy deals with the issue of when to create the BankAccount instance.