Seperating "model" from "view" GUI problem
Not sure what the best forum for this is but maybe some of you can point me in the right direction so I'll post it here
Anyway, I'm in the middle of learning java and taking the time to do some extra programming... I'm currently working on simple GUIs using AWT (for now!) and having a bit of a problem keeping mymodel andview seperate...
I have successfully implemented a (very simple) text based java game of blackjack, where the game just asks if you want to stick or twist by typing yes or no...
Now I just want to take it to the next level and have a window with 4 buttons ("deal", "twist", "pass" and "new game") and a TextArea that will display the text that was originally sent to the terminal prompt...
I have designed the primitive AWT GUI with a simple layout manager, but finding it difficult to get themodel andview to interact without puting theview in themodel and changing the println() statements to my own view.outputln() which appends the string to the textArea...
Thanks in advance!
[1095 byte] By [
TKennya] at [2007-10-3 2:39:48]
I think your problem is that
a) you don't have a model - otherwise you could ask it for its state and decide by that how to display something.
b) you have no clear separation between presentation tier and business tier - if those were separated by a clear interface, you could simply replace the classes using System.out with the classes using the textfield.
You have to correct that first. Program you game that the GUI can ask the model about what to display, and then display it, and that the controller can modify the model in any way necessary, using an interface like:
setUpNewGame()
getPlayerHand()
getBankHand()
drawCard(boolean isPlayer) // or bank
getGameState() // active, lost, won
Thanks for the reply, can you elaborate some more?
In general you need to think about separation of concerns. You want your model to be concerned with the card game, NOT the interaction with the user, that's the view's job. This means you don't want your model to do any input or output by itself (this includes actively calling view.outputln()).
Your model should just passively sit there and wait for requests to come in. It should then do everything needed to fulfill the request, but NOT the output. The view should request output upon succesful completion of the request.
So you want the view to call methods on the model to change or get the current state of the model (in the future, you might want to add a controller to take care of that, to fully implement the MVC pattern, but for now it's fine to integrate view and controller). Some methods your model might have were already provided by CeciNEstPasUnProgrammeur.
If you do it right, you should be able to have a console-based view and a GUI view both using the same model.
Thanks for clarifying that...
I guess "model" isn't really a model at the moment as it just runs through the simplified logic of the game then dumps out the results of the game, then when a human player is involved it waits for the user to type "yes" or "no" to whether they want to pass or not...
So in the GUI I would have to "wait" for the user to click the "pass" button, which isn't very event driven...
> So in the GUI I would have to "wait" for the user to
> click the "pass" button, which isn't very event
> driven...
This is exactly event-driven. Nothing happens unless there's an event from the button.
And no, your model doesn't sound like a model. It doesn't even sound like OO programming, rather than procedural stuff: put this in there, and get a result in the end. With objects, you can simply change their states, like hand values and ask them to give you some information.
Where's the difference between a ConsoleController calling the dealCardForPlayer() method of your interface when the user types "yes", or a SwingController calling the dealCardForPlayer() method of your interface when the user hits the "Another Card" button, or a BlackjackServlet calling the dealCardForPlayer() method of your interface when the user hits the "Another Card" button in his online HTML form generated by some JSP?
Being able to control your game without any user interface classes also helps testability. You can simulate a user and check for the expected results.
The code is written from some stubs* I found on the internet (http://www.cis.upenn.edu/~matuszek/cit591-2001/Assignments/card-game.html) its 2001 so its not my work, its something I found which seemed like a good challenge...
Anyway, later on the project evolves to including a GUI** with the game, so to keep it simple at first I was just going to add a textArea and some buttons to display the output of the game, then hopefully moving on to using "cards"...
*(http://www.cis.upenn.edu/~matuszek/cit591-2001/Assignments/Game.java
http://www.cis.upenn.edu/~matuszek/cit591-2001/Assignments/Dealer.java
http://www.cis.upenn.edu/~matuszek/cit591-2001/Assignments/Player.java)
**(http://www.cis.upenn.edu/~matuszek/cit591-2001/Assignments/card-game-gui.html)
It is a good challenge, and I'm pretty sure that you'll have learnt a lot after you're done. (No doubt that you can do it.)
But especially since you keep expanding and replacing components of your application, you should plan to keep it as modular as possible right from the beginning. "Keeping it simple" by not separating responsiblilites almost always gets you into problems later.
A few months ago I was bored and created a MasterMind. I planned to use a Swing GUI for it, but didn't feel like doing all the work and simply replaced the GUI part with console output. I didn't have to change anything in my game code.
