Proxy objects can be easily created by defining a simple class that works as an intermediate entity for another one (this resembles the concept of proxy servers). In this case, the proxy is responsible for accessing a class in particular, which will be instantiated only when its functionality is required.

Actually, the above definition seems rather hard to grasp, so let me show you an illustrative example where a proxy class is created to access a generic XML processor only when this object is needed by a specific application.

Having said that, here is the initial signature that corresponds to the mentioned proxy class, which not surprisingly I called "ProxyXMLProcessor." Have a look at the definition for this new class, please:

// define 'ProxyXMLProcessor' class (proxy class for XMLProcessor)

class ProxyXMLProcessor{

	private $XMLProcessor=NULL;

	private $xmlstr;

	// XMLProcessor is not created here by the constructor

	public function __construct($xmlstr){

		$this->xmlstr=$xmlstr;
	}

	// display nodes

	public function displayNodes($node){

		// XMLProcessor object is only instantiated when any 

of its methods is called

			if($this->XMLProcessor==NULL){

				$this->createXMLProcessor();

			}

			return $this->XMLProcessor->displayNodes

($node);
}

	// fetch nodes as array of objects

	public function fetchNodesAsObjects(){

		if($this->XMLProcessor==NULL){

			$this->createXMLProcessor();

		}

		return $this->XMLProcessor->fetchNodesAsObjects();
	}

} 

If you take some time and examine the class shown above, then you'll realize that undoubtedly there are some interesting aspects concerning its definition. First, the referenced proxy class really behaves as an intermediate entity for an XML processor object, since all the methods that belong to it are accessed via the proxy. This concept is simple, right?

In addition, you can see that the previous "ProxyXMLProcessor" class also offers a couple of straightforward methods for fetching and displaying the nodes of an inputted XML string. However, one thing that surely caught your attention is the fact that these methods will instantiate the corresponding XML processor object via the respective "createXMLProcessor()" method only when its functionality is required. Period.

Now, do you see why this pattern is aimed at avoiding the unnecessary instantiation of different objects? I hope you do!

Now that you hopefully grasped the logic that stands behind the proxy pattern, let me go one step further and show you how to improve the "ProxyXMLProcessor" class by expanding its existing functionality, in addition to implementing its still undefined "createXMLProcessor" method.

As you might have guessed, all these tasks will be discussed in the following section, thus click on the link below and keep reading.