I was looking at extending the Guard functionality to allow it to let some methods through without authentication (i.e. GET and HEAD) while requiring it of others (e.g. PUT, POST, DELETE). It's a simple matter of checking the Request method against a list of methods that the class keeps, and either continuing with the authentication process or skipping straight to acceptance.
The Decorator pattern works well for this kind of mix-in approach - ideally, I'd be able to add this method-testing capability to any other Guard subclass I had. Problem is, the Guard class isn't terribly well-suited for this approach - I can work around the protected methods, but the fact that handle() is final means that I can't set up a Guard that delegates that method to another Guard, which I need to do to use the Decorator pattern. I've decided to move forward with a basic subclass approach for the method-filtering Guard, but I'm curious about two things: * Why does Guard.handle() need to be final? * Is there a decent way of using the Decorator pattern on the Guard class (or any other pattern that prefers to start with a clean, public interface)? Thanks, Chris Battey

