What is the purpose of a wrapper class that does nothing but delegate to the object it wraps?

Question

The specific example I have in mind is javax.servlet.ServletResponseWrapper:

public class ServletResponseWrapper implements ServletResponse {
    private ServletResponse response;

    /**
     * The default behavior of this method is to call setCharacterEncoding(String charset)
     * on the wrapped response object.
     *
     * @since 2.4
     */
    public void setCharacterEncoding(String charset) {
    this.response.setCharacterEncoding(charset);
    }

    /**
     * The default behavior of this method is to return getCharacterEncoding()
     * on the wrapped response object.
     */
    public String getCharacterEncoding() {
    return this.response.getCharacterEncoding();
    }

     /**
     * The default behavior of this method is to return getOutputStream()
     * on the wrapped response object.
     */

    public ServletOutputStream getOutputStream() throws IOException {
    return this.response.getOutputStream();
    }  

   /** and so on **/
}

ServletResponseWrapper does nothing. It only passes execution to the nested object. So ServletResponseWrapper cannot function unless there is some other class (let's say ServletResponseConcrete) which also implements ServletResponse and does the real work.

In what context would you be able to use ServletResponseWrapper that you couldn't just use ServletResponseConcrete directly? This make absolutely no sense to me. I don't see how it's useful for subclassing either. If I subclass ServletResponseWrapper, then I have to implement every function anyways, so why not just create a class that implements ServletResponse directly?

Answer 1

If I subclass ServletResponseWrapper, then I have to implement every function anyways, so why not just create a class that implements ServletResponse directly?

This is not true. The whole idea of the class is, that one could use it as a base class to inherit from and just has to overwrite the method(s) that need to be changed. If you use the interface directly, you would have to implement all of the methods.

In what context would you be able to use ServletResponseWrapper that you couldn't just use ServletResponseConcrete directly?

One could provide a method that accepts a parameter of type ServletResponse or ServletResponseWrapper without knowing that there is a implementation called ServletResponseConcrete. Or maybe ServletResponseConcrete doesn't even exists yet. Still, you could later on implement ServletResponseConcrete or MyOtherServletResponse and hand it to that method.

This pattern is called "Delegation". Here is a simple example of an implementation that adds a System.out when setLocale is called:

import javax.servlet.ServletResponse;
import javax.servlet.ServletResponseWrapper;
import java.util.Locale;

public class TimsServletResponse extends ServletResponseWrapper {

    public TimsServletResponse(ServletResponse response) {
        super(response);
    }

    @Override
    public void setLocale(Locale locale) {
        super.setLocale(locale);
        System.out.printf("setLocale was called (locale: %s)", locale);
    }
}

Create a Filter to make your application server use your wrapper like this:

import javax.servlet.*;
import java.io.IOException;

public class TimsFilter implements Filter {

    @Override
    public void init(FilterConfig filterConfig) { }

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

    @Override
    public void destroy() { }
}

Answer 2

The example provided in the documentation is, strictly speaking, useless by design. If you follow the example you should have successfully implemented a wrapper class that has basically no meaningful effect on the system whatsoever. It should pass all proper tests, throw no weird errors, and cause no bizarre bugs.

However, if you follow the documentation you learn to create a proper wrapper class, and to hide the private implementation details that are unique to your systems. The example also shows a minimal default implementation of the ServletResponse interface, which would be handy if you needed a class that implemented this interface.

So why use something that doesn't do anything? Well, there is an implied Step 2 - make it do something useful that is specific to your system requirements. Maybe you only support certain character sets, or you always inject something into the ServletResponse, or you have some special write-behind handling when reset() is called.

As to why have both a wrapper and a concrete implementation, the wrapper basically does the minimum required to wrap the underlying object, and that's it. You then use the wrapper to code to the interface, while the concrete implementation is full of the system-specific implementation details that makes real world development messy and challenging.

The wrapper should be boring - the concrete implementation is where things get interesting. Yet if you need to swap out the implementation - such as as to support different platforms, architectures, environments, or particular applications - all you do is hand in a different Concrete class, and your wrapper won't complain or burden other systems to know about your classes at all. So long as they implement the right interface (which your wrapper does), they'll be happy.

This is very common in educational/documentation settings - the example given is the most minimal application of the concept, and it usually seems absolutely pointless. But once you know the use for something and the principles, then later the documentation serves as an excellent reference to implement the simplest thing possible that lets you start working on the tough bits.

Answer 3

The key utility of this class has to do with how you use it.

Yes, as written the class is useless. But it isn't meant to be used directly - its just something to pass through values. But what if you want to override one method there on top of the response you've got in your hand.

Well, you could create a new .java file that does everything you want it to.

Or, you could use an anonymous class.

Consider the code:

public ServletResponse filter() {
    ServletResponse resp = something();
    /* I don't care, I  always want it to be 'UTF-8' */
    return new ServletResponseWrapper(resp) {
        @override
        public String getCharacterEncoding() {
          return "UTF-8";
        }
    };
}

Granted, this is a trivial one that could have been done by calling a setter in the response itself, but you get the idea of what it could be used for.

And there you have a very nice and concise bit of code that uses the ServletResponseWrapper. While the wrapper is useless as is, it facilitates other code that is not useless. The alternative code to this is significantly more verbose and the essential information about what it does may be lost in that verbosity.