Understanding the Proxy Design Pattern

I have been working on Spring Aspect Oriented Programming (AOP) for some time now and for people new to this, it’s the Spring module that lets developers deal with the cross cutting concerns in their application modules. Spring has implemented AOP module based on the proxy design pattern. I will try and write more about Spring AOP in my blogs ahead but to start with, its important we understand what proxy pattern is all about and it’s design philosophy.

For newbies, let me begin with a very unconventional example to illustrate proxy pattern.

Here, in the above figure, we have three key characters… The Bridegroom seeking a girl’s hand in marriage. Bride, a delicate, sophisticated, daddy’s treasured pearl, and … yeah yeah, what not! Aunty (Proxy) Aunty, Grandma, Proxy, you name it. She’s here to protect the bride from bridegroom’s objectionable questions, and evil traps that he may have plotted. (I know it’s all in their heads, right? Still…) YES, we’re talking about a potential marriage! The 3 very common characters that we find in what’s perhaps the first phase of a typical Indian marriage; when a bridegroom comes to meet the bride and of course, her family too.

So every question that the bridegroom throws at the bride will actually be passed on to her via a round of filtering by her aunt. So the aunt could manipulate or modify his question and her answer at her will for she’s acting as an interface between the bride and the bridegroom. That’s bad isn’t it ? Perhaps yes from a marriage point of you but certainly not when it comes to software systems. This is exactly how proxy pattern works though.

A proxy, in its most general form, is a class functioning as an interface to something else. The proxy could interface to anything: a network connection, a large object in memory, a file, or some other resource that is expensive or impossible to duplicate.

Let me give you a more realistic example. If you wanted to drawback some cash from the bank, you wouldn’t be going to a bank branch. Instead, you will have to go to the nearest ATM and get the cash. So, in a sense we could say that ATM is also some kind of a bank but with reduced functionalities. Here, from the context of the design pattern, I can say that the ATM is some kind of a bank with reduced functionalities. Rather ATM is also a proxy to the bank! Consider the diagram below.

You see the common interface Bank here which comes with a set of method signatures. Both the classes ATM and BankBranch implementsthis interface. Now, when a person goes to an ATM and withdraws certain amount of money, the system actually invokes the withdraw() functionality on the proxy object which is the ATM instance in this case and then the proxy invokes the withdraw() method of the BankBranch instance from within it. The BankBranch instance has the actual implementation of the functionality and so its called the real object.This way the ATM proxy gets to handle some additional processing or actions before/after it makes the actual withdraw() call on the real instance of BankBranch. Now its possible that the proxy object might not have actual implementations to all interface methods and so in some scenarios like that of changePersonalInfo() , it could just override the method but giving away a proper access restriction message.

Lets have a look at the above example’s object and sequence diagram :

So the above example of ATM banking can be summarized from a proxy pattern perspective in the following points :

Subject (Bank) : The common interface for the proxy and the real subject.

Real Subject (Bank Branch) : The concrete subject that implements the interface.

Proxy (ATM) : Provides the same interface as Real Subject (or a subset).

• Maintains a reference to the Real Subject.
• Since it does not have all the data as Real Subject (a lightweight), it can do many things faster than Real Subject.Then invokes Real Subject (if needed).

Proxy pattern comes into play when :

• We have Heavy Weight objects and we want to implement a simpler version of it.
• We don’t need the whole functionality of the Heavy Weight object.
• We want to limit the access to the Heavy Weight object.
• Because there may be a time-delay or complex mechanism in creating instances of Heavy Weight objects.

Now as the common saying goes that every good things come with a set of drawbacks, here are few common issues that proxy pattern comes with in general :

• Identity Comparison : We can’t do identity comparison since we don’t know exact real subject, just a surrogate.
• Ambiguity : Client may not be aware that the real subject it is accessing now is not same as the previous one.
• Security Concern: Because client does not know what else proxy is doing, other than calling real subject.