The proxy battle is our last structural design pattern proxies are usually entities that represent other
entities and the proxy design pattern does just that.
It acts as another object.
It is basically a class that serves as an interface between a client application and another object.
The typical usages for the proxy button are.
When we need to create a rapport to cover the main object's complexity from the client or when we need
to ensure the security of a given resource and we need a proxy to check if the client is allowed to
access a resource that the proxy is representing.
This is a typical UML diagram to the proxy battle.
In our code, we would have a server which serves one file to the client application.
However, the client will call the server directly, but it will ask the proxy for the file, the proxy
will ensure that the client is entitled to receive the file, and if yes, then it will access the original
resource on the client's behalf and will serve the file to the client.
The witnesses for this pattern are.
We can have only one proxy, therefore, if you want to do error handling, security handling or one
to manage other aspects of dealing with the original resource, then you will have to do it in a single
class.
Also, it provides another layer of abstraction which can increase the complexity of the program.
Let's have a look at the implementation of this pattern in the code.