Hi Chris,
Thanks for the interesting design challenge :)
> * Why does Guard.handle() need to be final?
Actually, this is Filter.handle() that is final. The idea is to enforce the
filter contract which is to call beforeHandle(), then doHandle() and finally
afterHandle(). And currently, all the logic of Guard is implemented via the
doHandle() method.
> * 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)?
The way I would implement is:
public DecoratorGuard extends Guard{
private Guard decoratedGuard;
@Override
public void doHandle(Request request, Response response) {
if(request.getMethod().equals(Method.GET){
if (getNext() != null) {
getNext().handle(request, response);
} else {
response.setStatus(Status.CLIENT_ERROR_NOT_FOUND);
}
} else {
super.doHandle(request, response);
}
}
}
Best regards,
Jerome
> -----Message d'origine-----
> De : news [mailto:[EMAIL PROTECTED] De la part de Chris Battey
> Envoyé : mardi 26 juin 2007 01:11
> À : [email protected]
> Objet : Guard and the Decorator pattern
>
> 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
