This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
The moose likes OO, Patterns, UML and Refactoring and the fly likes OO design - event handling Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "OO design - event handling" Watch "OO design - event handling" New topic
Author

OO design - event handling

Alex McCormick
Ranch Hand

Joined: Mar 08, 2003
Posts: 31
Hi all, quick question on event handling as it relates to OO design. I'm a relative novice to Java (and programming in general) and am building a card game program. Without going into specifics, I'm struggling with how to handle the flow of the game from player, to computer, and back again. For instance, the user would choose a card in his or her hand to play. Then, the computer will play a card. Now, it's the user's turn to play another card, and so on and so forth.
I've got a number of classes in my program, one being the GUI class and another being the gameFlow() class which handles (or is supposed to handle) the back and forth of the flow of the game. I've got the actionPeformed() method in my GUI class - but the only event handling I know how to do is the basic:
...if (event.getEvent() == startbutton) {
do this;
do that;
}
if (event.getEvent() == exitbutton) {
do this;
do that;
}
etc, etc.
This is how I was taught event-handling - which works fine for simple things like starting or ending the game, but it doesn't seem to be appropriate for situations in which the program is waiting for some type of response from the user (choosing a card to play, for instance). I would think there's a better way to do this, but I just don't know how.
Then again, maybe that IS how I'm supposed to do things.... Any help or advice would be greatly appreciated. I realize my question is pretty generic, but I didn't want to post a bunch of code when that might not really be necessary. In addition to creating a working program, I really want to strive to use good OO design wherever possible. This is a learning experiance, and I'd rather take the time to do it right, rather than cobble something together that works but is architected poorly.
TIA!!
Nicholas Cheung
Ranch Hand

Joined: Nov 07, 2003
Posts: 4982
I did similar thing when I took the SCJD assignment. In such case, you can make use of MVC model. Your Java Applet or application is the view, and your cards are data, while you need to have a controller class.
Thus, for any response from the GUI, the event handler captures it, however, it only extracts necessary data from the event, say, which card is shows by the player, and pass all data to the controller, and let the controller to determine whether the do this or do that, whether the system should wait or give response.
Nick


SCJP 1.2, OCP 9i DBA, SCWCD 1.3, SCJP 1.4 (SAI), SCJD 1.4, SCWCD 1.4 (Beta), ICED (IBM 287, IBM 484, IBM 486), SCMAD 1.0 (Beta), SCBCD 1.3, ICSD (IBM 288), ICDBA (IBM 700, IBM 701), SCDJWS, ICSD (IBM 348), OCP 10g DBA (Beta), SCJP 5.0 (Beta), SCJA 1.0 (Beta), MCP(70-270), SCBCD 5.0 (Beta), SCJP 6.0, SCEA for JEE5 (in progress)
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
Originally posted by Alex McCormick:
This is how I was taught event-handling - which works fine for simple things like starting or ending the game, but it doesn't seem to be appropriate for situations in which the program is waiting for some type of response from the user (choosing a card to play, for instance). I would think there's a better way to do this, but I just don't know how.

The applications I've written have basically done what you post, except that instead of including the execution code in the actionPerformed() method - which quickly leads to major spaghetti code - it calls an appropriate function, instead.
The way I would do it is to call a function within the GUI class that would handle the immediate changes in the GUI (e.g., highlighting the selected card), then call the game flow class if appropriate to do the appropriate things with respect to the game. The game flow class might then call back to the GUI class if some of the game results needed to be displayed.
Nicholas Cheung
Ranch Hand

Joined: Nov 07, 2003
Posts: 4982

The way I would do it is to call a function within the GUI class that would handle the immediate changes in the GUI

Huh... Maybe it is better to have a controller class, which knows how to handle all possible events, instead of putting all things in the GUI class.
In the point of view of code reuse and maintanence, it is easier to reuse, as maybe we will have another card game that can use some pieces of code.
This approach is similar to MVC model 1, which the view also performs the controller tasks.
For coding issues, both methods work. But for design (or OO) issues, seems applying patterns will be better. Of course, for simple systems, patterns may not be that useful. But in the view of a learning process, it is a good chance.
Nick
Alex McCormick
Ranch Hand

Joined: Mar 08, 2003
Posts: 31
Thanks for the replies guys. Maybe I need to learn more about the MVC philosophy... Any good links you could recommend?
Richard Quist
Ranch Hand

Joined: Feb 18, 2004
Posts: 96
Originally posted by Alex McCormick:
Thanks for the replies guys. Maybe I need to learn more about the MVC philosophy... Any good links you could recommend?

You might try searching at javaworld in addition to here on the ranch
[ April 20, 2004: Message edited by: Richard Quist ]

Rich
SCJP 1.4
Nicholas Cheung
Ranch Hand

Joined: Nov 07, 2003
Posts: 4982
You may read this link:
http://ootips.org/mvc-pattern.html
Nick
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: OO design - event handling