Class design

Question

I have 2 classes for the game i am making,

gui class and the logic class, for a game of noughts and crosses. The GUI class has a method that uses an array of JButtons and returns them all with the same anonymous inner class action listener

The problem is this, when i click the button i want the text to change to an x or a o dependant on player 1 or 2 go, but this code should be in the logic class shouldnt it so somehow i should be making a method in the logic class and calling it from the anon inner class action listener of the make button method. However, the logic class shouldnt have a reference to the gui, as the gui has a reference to the logic class,

i cant think of a decent solution to this

thanks

Answer 1

Hi,

maybe use an event. So you may react on the GUI side of the calculations of the logic and simply do as commanded ;)

Answer 2

Using the same instance as an action listener for multiple buttons is almost certainly a bad idea. Use a separate instance of the same implementation class parameterised with the position of the button. The listener can then invoke the model using an interface which is appropriate for a model.

Answer 3

If your focus is on design (this sounds like homework), you could try MVC (Model-View-Controller).

In this case,

model = game logic, rules (fire events when things change)
  gui = (in this case and many swing apps) is both view and controller. Manipulates the model (control) and the model fires events back to update the widgets (view)

Answer 4

Hi,

I don't find that the bi-directional references (GUI has reference of the model and vice-versa) should be a problem. I think the kind of thing you're searching for is a MVC (Model-View-Controller) approach. I don't know which programming language you're using to program that game and whether to apply this approach may be an overhead in this context. I've written a small demo of a MVC approach in Java: http://blog.js-development.com/2008/03/logical-separation-with-mvc.html

Maybe it helps you, let me know.

Answer 5

When the button click occurs, your GUI calls the logic to inform it that the current player (logic knows current player) clicked the grid somewhere. Then the logic updates the state (update grid, update current player, ...) and sends an event back to the GUI to inform the GUI it has to update itself.

The GUI "knows" about the logic to call operations. To avoid the logic from knowing the GUI and have good separation of concerns, the logic should be coupled to the GUI via the Observer pattern, instead of the logic calling the GUI directly. The GUI listens to events from the logic. The logic then is only dynamically coupled to the GUI, which isn't a problem.

Answer 6

Consider the following sketch of classes:

public class Game{
    public void switchPlayer(){
        // among other things calls all GameListeners
    }
    public void setMarker(int x, int y);

    public Player getCurrentPlayer();
    public Player getPlayerOwningField(int x, int y);

    public void registerGameListener(GameListener l);
}

public interface GameListener(){
    void gameChanged(Game g)
}

public class GUI implements GameListener(){
    private Game game;
}

When a field is clicked, game.setMarker(x,y) is called. The game know who the current Player is, so it can mark the field apropriately. It will also fire a GameChanged event. During setup of the application the gui must get registered / register itself as a GameListener to the game. So it will get informed as well. It uses the getters of the game to update the gui. Done.

Of course there is plenty of room for refinement, e.g. in a large game it wouldn't be a good idea to update the complete UI just because one field got change, but it should get you started

Answer 7

save an event flag in a database or sth. like that and query this flag in your gui works like async. events

Answer 8

You could apply the MVC pattern.

The UI class (Controller) will send the message to the Logic class (Model), which will update the View (Class). You need to define this. It could be as simple as an array of boolean values.

The UI code will have to read the View class in order to change the text in the buttons. So, when View is changed, you need to send an "invalidate" message to the UI class, so that the buttons text is updated.

The key point here is that the UI code consults a View object to render the buttons. It is perfectly right the UI class to read this object and the logic class to write it.