Maugrim_The_Reaper wrote:I'm not even sure a InterceptingFilter is required... it's a common pattern that may not be solving a problem in this instance - hence it needs changing. I'll assume so...
What I don't like about it is that it mixes up a whole range of objects with different responsibilities: validation, authentication, authorisation, logging - you name it. Everything including the kitchen sink. That makes me twitchy but it is a widely used pattern and I don't know if anyone would agree with me. Your choice - by all means stick with it if you like.
Personally I'd do the input validation in the Request object - session stuff too with methods like persist(), forget() and a pile of named getters and setters. That makes a Request more of an HttpContext rather than simply dealing with user input. A Gateway-type object makes it easier to switch to a command line version, in the possibly unlikely event you'd want to do so, and can help with testing since gateways are good points to mock/stub.
If you're TDD-ing, you've got to be careful not to try to look too far ahead. It's all about staying focussed on one small part of the problem, guided by well-defined requirements. Sometimes you just need to take your best guess - you can refactor later if it's not quite right. This works particularly well with OOP because it chimes with the idea of low coupling (
LawOfDemeter). If objects have the minimum of contact, different parts of the system don't interfere with each other. You can design one part safe in the knowledge that later choices about other parts won't affect it.
A Request object will interact directly with the FrontController so you have to invent an interface for it and decide what behaviours it should have. You'd stop there and come back to implement it once you're finished with the FrontController.
should the mapping to module/command values be in a Request object?
This is a FrontController responsibility - in fact the only thing unique to a FrontController. A Request object might have getCommand(), getModulePath() methods. Request knows how to interpret user input, the FrontController decides what to do with it. Basically that means mapping a request type to a "to do" list. PageControllers also have to load to do lists, but these can be hard coded since you already know what the request type is.
Finally, I'm very conscious that a lot of my advice is "tainted" with my own OOP style. I can't help that. A more experienced programmer than me would have seen it all, be able to suggest more options and explain the ins and outs of each. Just something to be aware of.