How to go about with real GUI development with Jav

Question

I am creating a Blackjack Card game emulator. I am a SCJP,familiar with Core Java concepts. I have a very basic understanding of Java swings and awt. Already finished writing the basic game logic,a CLI logic. My design includes several classes like, Dealer,Player,Table,Card,Casino and some others.. Enums for Cards and suite.

I have read about MVC as a theoretical concept, familiar with the name 'design patters'(no understanding whatsoever as to how they are implemented) Everywhere I am suggested to learn while writing some real code.So I started off with this...

I am stuck now, how should I go about writing code for my project?? Writing the GUI code and organising it within the already existent code.

Answer 1

Here is a simple example of how this could be split.

Presumably, a player's cards are represented as a 'hand' or a similar object (i.e. a collection of cards). This is your model. So lets call your model:

package casino.blackjack.model;
class DealtCards
{..}

You display your cards using maybe a JPanel or some other Swing construct. So you could put all the objects that actually do the rendering of each card in a seperate package:

package casino.blackjack.view;
class DealtCardsView
{..}

The DealtCards object exists independently of how it is displayed, but its state may change if a user does something on the GUI. For example, asking to be 'hit'. Presumably, there could be a button to do this. The view is derived from your model.

package casino.blackjack.view;
class DealtCardsView
{
  JButton hitMeButton = new JButton("HIT");
  DealtCards cards;

  public DealtCardsView(DealCards myCards)
  {
     cards = myCards;
     renderCards();
  }

  private void renderCards(){.. do something..}

}

Now, if a player decides to hit, his DealtCards object changes. So, we want to implement a way in which your model is updated. You can do this using a controller class. The controller class implements the ActionListener interface. When an action is performed (i.e. user clicks "hit" button), the controller updates the model. So the view cannot directly update the model. It just sends a notification that an 'action' has occurred. Any interested parties, in this case, our controller, can then take appropriate action.

package casino.blackjack.controller;
class DealtCardsController implements ActionListener
{
  DealtCards cards;
  DealtCardsView cardView;
  public DealtCardsController(DealtCards myHand, DealtCardsView myView)
  {
    cards = myHand;
    cardView = myView;
    cardView.hitMeButton.addActionListener(this);
  }

  public void actionPerformed(ActionEvent e) 
  {
    cards.changed();
  }
}

So you split your application in three layers. Your model just contains the current state (or current data), and any validation that goes around it. Your view classes render the model in an appropriate manner. Any user interaction, on the view, is handled by the controller, whose responsibility is then to update the model.
This way, if you want to change your view, (say use an applet instead of a window) your model doesn't care.
Sorry about the long winded reply, but hope that helps a little!

EDIT: A nice MVC explanation here: java / gwt UI coding - clean code

Answer 2

It took me ages to learn MVC (I got taught incorrect things about it in university, and additionally a lot of online sources at the time were wrong about it). Anyway, the core of you need to do is not have any view information in your model (i.e., what the player looks like on the screen, the framebuffer, the polygons of your models). Instead, you create the view and model in separate namespaces, and then use events to link the two together. When sometimes happens in your model, the view gets notified, and changes are made to the view. Additionally, when the mouse is pressed or a key is pressed, the input event gets transformed into another model-oriented event which can take the form of a method call into the model. Any changes in the model are then fed back onto the view.

Remember this: the model should be functional without the view being attached, and should not show anything on the screen while executing (except perhaps debug info in the console).