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: http://stackoverflow.com/questions/2320152/java-gwt-ui-coding-clean-code