If you had seen the show "Growning Pains" you must remember in one episode, Mike got a newspaper delivery job and he didn't want to deliver any of the newspapers. So he "outsourced" those newspapers to his brother Ben. And the postoffice gave Mike about 5 bucks but Mike only gave Ben 2.5 bucks for remuneration, so he could get 2.5 bucks without doing anything.
In postoffice's perspective, they gave Mike 5 bucks and 100 newspapers and no matter how Mike delivered those newspapers, as long as newspapers are sent on time, they will pay for Mike next time anyway(actually he messed it up in the end...). That is, the way Mike deliver newspaper is transparent to the postoffice. Mike could do it himself or let Ben to do this, or maybe Ben will also "outsource" his job to others, whatever.
Another example is related to the computer domain. You must have used proxy server in IE sometime before. You entered a proxy's IP address, say 222.111.0.0, and let this machine download the contents from internet for you. You don't know whether the proxy server connects other servers to download the contents and then forward to you or connect to the internet directly. Maybe the proxy goes to the States and then to Europe then back to China afterwards, who know? The thing is, you don't have to know the details! You will be statisfied if IE displays right stuffs, won't you?
In those 2 examples above, we could say, Ben is Mike's "proxy", the machine 222.111.0.0 is IE's proxy. Why Ben is a proxy? Because for Mike and the postoffice, Ben is the guy who actually do the delivery job. For the PC users and IE, machine 222.111.0.0 is the one who actually download the contents. You got it? Proxy is the one who do the real job. And what's more? Proxy could be replaced, it's very important, Mike may let Carol to do the same job if she is drunk I guess. In this case, the postoffice doesn't have to worry about how the newspapers is delivered, because Mike will handle it.
Ok, you must dope out what design pattern I'm gonna discuss today, right, the Proxy Pattern. Let's start from a real requirement. Jimmy wants to build a system which is able to communicate with another process to get some basic hardward information of a terminal. The process can either exist in the same terminal as the system or exist in other terminals. Terminals can be a mobile phone, can be a PC etc.
Let's take a look at the requirement, if the process is located in the same machine as the system, then IPC(inter-process communiation) may needed to deal with the data transferring. If the information is stored in a local database, then DB APIs need to be used. If the process is in another machine, then socket should be used to handle network operations. It's so inconvenient to handle all the situations. If someone else know how to do the specific job and we just say the order, that'll be great! What if we hire a agent? a proxy? Sounds nice. Here's a possible solution( example here and the example code are for inter-process communication, and I use Symbian client/server architecture to implement the IPC )
In the diagram, the end user talks to IPC(inter-process communication) client, this component is responsible to connect the server(another process) and get the information. What does "RemoteInfImpDll" do? I'll talk about this a little bit later. Let's see a more detailed class diagram.
According to the class diagram, class CRemoteInfProxy is corresponding to the package "ProxyIPCClient", class CRemoteInfImp is corresponding to the package "RemoteInfImpDll". They both inherit from the interface MRemoteInfHunter. Let me make the thing a little bit more clear by telling a metaphor, you can regard class CRemoteInfImp as Mike, class CRemoteInfProxy as Ben and class EndUserView as the postoffice. Postoffice(EndUserView) hire Mike(CRemoteInfImp) to do the job, but the postoffice(EndUserView) doesn't know who actually do the job, he thinks he only talks to Mike(CRemoteInfImp). But Ben(CRemoteInfProxy) will do the real job.
In order that the Postoffice(EndUserView) won't realize Ben(CRemoteInfProxy) is doing the job, Mike(CRemoteInfImp) must have the same appearacne(interface) as Ben(CRemoteInfProxy), that's why 2 classes are both inherited from the same interface MRemoteInfHunter. You may also notice the pointer from Ben(CRemoteInfProxy) to Mike(CRemoteInfImp), that means after Ben finishing the job, he must report to Mike to get the money, and Mike is the guy who decides how to deal with the 5 bucks! He can only give Ben 1.5 bucks if he wants. In this example, CRemoteInfProxy is responsible to get the hardware information from the other process, and CRemoteInfImp take care of the information saving logic.
Why do we need to do this? Because the way of getting the information will be changed, for example through network, database, etc. But the logic of saving it to a file won't be changed a lot, so we need to isolate the information getting logic so that we don't have to modify the file saving code and other code when we changing the way of getting information from another process. And the best place to put the isolated logic is the proxy class. See the detailed class diagram to see how this example do it.
From the diagram, we see class CRemoteInfProxy takes advantage of the Symbian Client/Server framework to get the hardware information. CRemoteInfProxy uses RRemoteInfServer, and RRemoteInfServer is the client side handle of the server object(refer to chapter 11, 12 of Symbian OS Explained John Wiley & Sons, Inc to know more details about Client/Server framework in Symbian OS). RRemoteInfServer connects the server and sends a message to the server to get the information.
Since the interfaces of CRemoteInfProxy and CRemoteInfImp are the same, EndUserView is aware of using the CRemoteInfImp object instead of CRemoteInfProxy. I can easily change the CRemoteInfProxy by anyother info getting class, one possible example is like the class diagram below.
Here, I use a complete different way to get the information. Through RSocket class, CRemoteInfProxy object can get the information from the remote process in another terminal. When CRemoteInfProxy object gets the information, it will create a CRemoteInfImp object to do the file saving logic.
Example code(the example code exclude UI can be compiled by both UIQ3 and S60 3rd SDK, UI can only be compiled by UIQ3 SDK):
Example code user guide:
This article is also published in www.NewLC.com
http://www.newlc.com/when-symbian-met-design-patterns-2-proxy-pattern
