Oh, I should have probably been more specific about this but the keyHandler and mouseHandler classes just hold a hashmap of which keys were pressed (for the keyHandler) and which location on the screen was clicked (for the mouseHandler). They don't handle the events (the JPanel uses key bindings and a mouse listener to do this), more so just store what event was triggered. Every game state would need access to these since I have to be able to processEvents in each game state. Same with each component of the screen (inventory, etc).
Ah ok, that makes more sense.
One of the things I've learnt in the last 15 months working on my current project is that I only ever come up with the "right" design for something at first attempt about 1% of the time. Sometimes it's not bad but needs tweaks. Other times it's awful. My current game engine has evolved a lot as I've added new functionality and decided some part of the design was flawed. I've actually spent a fair bit of time rewriting existing code, but each iteration the system becomes better and more logical in my opinion. So I've learnt to not stress too much about having a perfect design from day one.
Generally speaking though, one of the metrics I use to tell if something isn't "right" in my code is that there are ALOT of interdependencies going on, ie many references to other classes that are passed through into other classes. There's not always an obvious elegant solution however. Sometimes you just have to live with it.
