Java Decorator pattern example

Ok what the hell is the decorator pattern? Why do I need it?

Theory

I can not say that I am good explaining theory. I just read it and try to apply it where possible! After all practice and theory, theoretically are exact the same! So If you are intrested in theory, I thing that this article at Wikipedia can explain pretty well what it is all about. But if you are like me I do not know if you will remember what exactly is and where to use it if you haven't used it at least once!

A real example using the Decorator pattern

The funny thing is that I've been using this pattern a lot (even if I did not realize it from the first moment) and I'm pretty sure that many of you have. Where? Within every web application that uses the servlet directly. The scenario is that I want to make sure that when I use the getRemoteAddr() of a request I should always first check if there is an X-Forwarded-For header within the request and if so use that ip address. The solution is a custom HttpServletRequest. The servlet api gives us the tool in order not to have to write a lot of boilerplate code which is called HttpServletRequestWrapper. The class should look like the one below.

public class XFFAwareReq extends HttpServletRequestWrapper {
  
  public XFFAwareReq(HttpServletRequest request) {
    super(request);
  }

  @Override
  public String getRemoteAddr() {
    String xff = getXForwardedFor();
    return xff != null ? xff : super.getRemoteAddr();
  }

  public String getXForwardedFor() {
    String xff = getHeader("X-Forwarded-For");
    if (xff == null || "".equals(xff)) return null;
    return getIpFromXFF(xff);
  }

  protected static final String getIpFromXFF(String xff) {
   //extract and return the ip from the X-Forwarded-For header
  }
}

If you are also intrested in how to actually use it,that is with a Servlet filter:

public class HttpServletRequestDecoratorFilter implements Filter {
  @Override
  public void init(FilterConfig filterConfig) throws ServletException {
    //do nothing
  }

  @Override
  public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
    
    request = decorate(request);
    chain.doFilter(request, response);
  }

  private ServletRequest decorate(ServletRequest request) {
    try {
      HttpServletRequest req = (HttpServletRequest) request;
      return new XFFAwareReq(req);
    }
    catch (ClassCastException e) {
      // As we are not able to cast the request to an Http one, we just return the same object
      return request;
    }
  }

  @Override
  public void destroy() {
    // Do nothing
  }
}

Cool, but where is the power of decoration? We just wrapped a class providing some more logic to it. Well, the other day you have the request to prevent your site from xss attacks. A way to do that is to filter the request parameters and strip or escape bad characters or group of characters. Of cource we can just add some functionality to our existing class (XFFAwareRequest) and also rename it to reflect the new functionality added. This solution thought breaks the principle of separation of concerns. What we do then? Easy, create another decorator to provide the new functionality (and only that) overriding the getParameter method and replacing or removing the bad stuff.

public class XSSAwareReq extends HttpServletRequestWrapper {

  protected XSSAwareReq(HttpServletRequest req) {
    super(req);
  }

  @Override
  public String getParameter(String name) {
    return super.getParameter(name)
      .replaceAll("<", "&lt;")
      .replaceAll(">", "&gt;")
      .replaceAll("\\(", "&#40;")
      .replaceAll("\\)", "&#41;")
      .replaceAll("'", "&#39;")
      .replaceAll("eval\\((.*)\\)", "")
      .replaceAll("[\\\"\\\'][\\s]*javascript:(.*)[\\\"\\\']", "\"\"")
      .replaceAll("script", "");
  }
}

Then all you have to do is to decorate a little bit more the first HttpServletRequest which is as easy as adding the line req = new XSSAwaareReq(req) before the return new XFFAwareReq(req); one letting the XFFAwareRequest untouchable and not breaking for example existing tests! Now you know that you've used the decorator pattern with in your web apps!