-
Notifications
You must be signed in to change notification settings - Fork 246
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
QueueProvider rework suggestion #258
Comments
This is definitely the way to go. Supports clean code and makes testing much easier. |
Some things I was wondering while starting the rework:
|
It isn't needed if QueueProvider is refactored.
The QueueProvider is mostly used in stand-alone games. The client/server connection is managed in Client and JAdventure. The QueueProvider is used to send messages from the server to the client, with the game logic happening on the server |
As I was talking about in #196, I've been trying to figure out how to write JUnit tests for the menu classes. Without changing QueueProvider, I'd have to use System.setIn/setOut to test the menus.
Looking at QueueProvider, I'm thinking it would maybe work better as a singleton, and then a small hierarchy of QueueProvider like classes - a base, abstract class (or interface?) QueueProvider, with subclasses like TestingQueueProvider for testing, and other subclasses for standalone and server/client QueueProviders.
startMessenger() would then create the singleton instance variable in QueueProvider, which would be accessed with QueueProvider.getInstance() to use offer() and take() as before, or maybe getQueueProvider() which could be statically imported to make things a bit cleaner.
So that would make testing with the QueueProvider a lot cleaner (since you'd be overriding take() and offer() to store output etc) and also mean you don't need things like if (GameModeType.SERVER == mode)... in QueueProvider.
Just an idea. Is that too much?
The text was updated successfully, but these errors were encountered: