A Brief Analysis of the Proxy Pattern in Design Patterns

Proxy Pattern

1. Establish a proxy object (proxy) between the client and the entity. All operations the client performs on the entity are delegated to the proxy object, hiding the entity's specific implementation details.

2. Proxy can also be separated from the business code and deployed to another server. Tasks are delegated via RPC in the business code.

Similarities and Differences Between the Proxy Pattern and Parent Classes and Interfaces

• Similarities: The role of the proxy pattern is similar to that of parent classes as well as interfaces and composition; all of them are meant to aggregate shared parts and reduce code for common parts
• Differences:
  • Compared to parent classes, their contexts are different; what a parent class expresses is is-a, while what a proxy expresses is closer to an interface, which is has-a, and using a proxy also fits the saying "use less inheritance, use more composition"; what it really means is reducing coupling
  • Compared to interfaces, the functions they implement are somewhat different; the context is has-a in both cases, but an interface is has-a-function, while a proxy object is has-a-object, and this object is a has-a-function object; moreover, an interface is meant to indicate what capabilities this class has, without a concrete implementation, achieving polymorphism, whereas a proxy object not only possesses this capability, but also possesses the concrete implementation of this capability
  • As for composition, it is more flexible than composition; for example, if we set the proxy object as private, then I can choose to provide only part of the proxy functionality, such as one or two methods of Printer, or add some other operations when providing Printer's functionality; all of these are possible

Implementation Code

class Printer {    //代理对象,一台打印机
	public function printSth() {
		echo 'I can print <br>';
	}
	
	// some more function below
	// ...
}
 
class TextShop {    //这是一个文印处理店,只文印,卖纸,不照相
	private $printer;
	
	public function __construct(Printer $printer) {
		$this->printer = $printer;
	}
	
	public function sellPaper() {    //卖纸
		echo 'give you some paper <br>';
	}
	
	public function __call($method, $args) {    //将代理对象有的功能交给代理对象处理
		if(method_exists($this->printer, $method)) {
			$this->printer->$method($args);
		}
	}
}
 
class PhotoShop {    //这是一个照相店,只文印,拍照,不卖纸
	private $printer;
	
	public function __construct(Printer $printer) {
		$this->printer = $printer;
	}
	
	public function takePhotos() {    //照相
		echo 'take photos for you <br>';
	}
	
	public function __call($method, $args) {    //将代理对象有的功能交给代理对象处理
		if(method_exists($this->printer, $method)) {
			$this->printer->$method($args);
		}
	}
}

$printer = new Printer();
$textShop = new TextShop($printer);
$photoShop = new PhotoShop($printer);

$textShop->printSth();
$photoShop->printSth();

Both the print shop and the photo shop have printing functionality, so we can proxy the printing functionality to a printer. Here the printer has only one function; if the printer also had n functions, using the __call() method we could save a lot of duplicated code

If we used inheritance, the context would be unreasonable; a shop clearly should not inherit from a printer

And if we used an interface, because our function implementations are all the same, there is also no need to re-implement the interface's functions

So using a proxy here is the best choice

Java's Proxy Pattern

The implementation of the proxy pattern in Java is actually similar, except that Java does not have a __call() method, so you need to manually declare the printSth() method, then call $printer's printSth() method in the method body Alternatively you can use the InvocationHandler proxy interface to implement the proxy,

public interface InvocationHandler { 
   public Object invoke(Object proxy, Method method, Object[] args) throw Throwable; 
}

//日志代理实现   
public class LogHandler implement InvocationHandler{ 

   private Object target; 

   public LogHandler(Object target){ 
       this.target = target; 
   } 
   public Object invoke(Object proxy, Method method, Object[] args ) throw Throwable{ 

       //记录函数的初始状况参数等信息 
       log4j.info(“开始:方法”+ method.getName() + “参数”+Arrays.toString(args) );

       Object result = method.invoke(target, args); 

       //记录函数的执行状况与返回值 
       log4j.info(“结束:方法”+ method.getName() + “返回值”+ result ); 

   }
}

//主函数   
public class Main{ 
   public static void main(String[ ] args){ 
	   //例子中生成报告的功能，生成报告需要记录日志。
       ReportGenerator reportGeneratorImpl  = new SMSReportGenerator (); 

       //通过系统提供的Proxy.newProxyInstance创建动态代理实例 
       ReportGenerator reportGenerator = (ReportGenerator ) Proxy.newProxyInstance(  
           reportGeneratorImpl.getClass().getClassLoader(), 
           reportGeneratorImpl.getClass().getInterfaces(), 
           new LogHandler(reportGeneratorImpl)
       ) ; 
       ...
   }
}

However, the structure of dynamic proxies implemented with the Java Reflection API is very complex and not easy to understand. Friends who have used the Spring framework should be somewhat familiar with Spring's AOP (slice-oriented programming). Spring's use of annotations to implement the proxy pattern is much more intuitive than the Java Reflection API approach. This article will not go into further detail.