The Proxy Pattern — A Simple Guide

“man raising his hands while praising” by Nicole Honeywill on Unsplash

The proxy design pattern is one that i don’t see used in production systems very frequently. I also hear one overwhelmingly loud question: “How is this different from the Decorator Pattern?”. In order to answer this question, lets consider the analogy that the proxy pattern represents. Suppose your home town is going to have a town meeting, and all residents are invited. The meeting, however, happens to be on a day when you will be out of town on vacation. You could designate someone as your ‘proxy’ to stand in for you on any town decisions. This individual has your explicit trust and can speak for you, vote for you etc during the town meeting.

The proxy design pattern has a similar goal. The ‘proxy’ is designed as a stand-in, it can make decisions in place of the ‘Subject’ (Lets call the one that the proxy is standing in for, the ‘Subject’.) or possibly call out to the subject when it cant make a decision. Here is the important distinction between a proxy and a decorator: The decorator is designed to add behavior to ANY implementer of an interface, where the proxy is designed to stand in for a specific implementer of an interface. In fact a proxy could be said to be a special, less generic type of decorator. Let’s look at an example.

One of the most well known examples of the proxy pattern is the “Remote Proxy”. The remote proxy stands in for a server side subject. It implements the interface so that the client doesn’t need to know or care that the actual implementer is server side. Take the interface:

public interface IFooService 
{
    IEnumerable<Foo> GetSomeFoos();
}

The implementer of the interface could look something like this:

public class Service : IFooService 
{
    private dal = new FooDAL();
    public IEnumerable<Foo> GetSomeFoos()
    {
        return dal.GetFooList();
    }
}

The implementer does not care whether it is being called from a web service, or directly through a win-forms client, or a windows service etc. However if you wanted to host a web service with this logic in it, it would be a great use case for the proxy design pattern. Suppose you have an endpoint that looks like: https://mydomain.com/foos which will call ‘GetSomeFoos’ on the service. Now you could have a FooServiceWebProxy that will implement IService, then call the endpoint and return the results.

public class FooServiceWebProxy : IFooService
{
    public IEnumerable<Foo> GetSomeFoos()
    {
        System.Net.Http.HttpClient client = 
            new System.Net.Http.HttpClient();
        var foos = 
            client.GetAsync("https://mydomain.com/foos").Result;
    }
}

The proxy in this instance is not generic like a decorator. It is tied to a specific implementation of the service. To compare check out my article on decorators here.

Now the proxy could add additional behavior like authentication, validation etc. if required. Or, those things could be handled by decorators and adapters added on top of the proxy. One advantage of wrapping your proxy in decorators is that the decorators don’t care whether they are wrapping a proxy, or the original implementation. You could easily build your infrastructure to support either direct database access, OR using web services by subbing in the proxy on the flick of a switch.

I know this one is pretty short but that is kinda the point. Hopefully y’all enjoyed the post and please respond if there is a pattern or design principle you would like me to write about next!