Comment procéder avec le développement réel de l'interface graphique avec Java Swing et MVC


Je crée un émulateur de jeu de cartes Blackjack. Je suis un SCJP,familier avec les concepts Java de base. J'ai une compréhension très basique de Java swings et awt. Déjà fini d'écrire la logique de jeu de base, une logique CLI. Ma conception comprend plusieurs classes comme, Croupier, Joueur,Table,Carte, Casino et quelques autres.. Enums pour cartes et suite.

J'ai lu à propos de MVC en tant que concept théorique, familier avec le nom 'design patters'(aucune compréhension quant à la façon dont ils sont implémentés) Partout on me suggère d'apprendre tout en écrivant du vrai code.So J'ai commencé avec ça...

Je suis coincé maintenant, comment dois-je écrire du code pour mon projet?? Écrire le code GUI et l'organiser dans le code déjà existant.

Author: Jonas, 2010-02-23

2 answers

Il m'a fallu du temps pour apprendre MVC (on m'a appris des choses incorrectes à ce sujet à l'université, et de plus, beaucoup de sources en ligne à l'époque se trompaient à ce sujet). Quoi qu'il en soit, le cœur de vous devez faire est de ne pas avoir d'informations de vue dans votre modèle (c'est-à-dire à quoi ressemble le lecteur à l'écran, le framebuffer, les polygones de vos modèles). Au lieu de cela, vous créez la vue et le modèle dans des espaces de noms distincts, puis utilisez des événements pour lier les deux ensemble. Lorsque cela arrive parfois dans votre modèle, le la vue est notifiée et des modifications sont apportées à la vue. De plus, lorsque la souris est enfoncée ou qu'une touche est enfoncée, l'événement d'entrée est transformé en un autre événement orienté modèle qui peut prendre la forme d'un appel de méthode dans le modèle. Toute modification du modèle est ensuite renvoyée sur la vue.

Rappelez-vous ceci: le modèle doit être fonctionnel sans que la vue soit attachée, et ne doit rien afficher à l'écran lors de l'exécution (sauf peut-être les informations de débogage dans la console).

 2
Author: Chris Dennett, 2010-02-23 18:25:18

Voici un exemple simple de la façon dont cela pourrait être divisé.

, Vraisemblablement, les cartes d'un joueur sont représentés comme une "main" ou un objet similaire (c'est à dire une collection de cartes). C'est votre modèle. Appelons donc votre modèle:

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

Vous affichez vos cartes en utilisant peut-être un JPanel ou une autre construction Swing. Vous pouvez donc mettre tous les objets qui font réellement le rendu de chaque carte dans un paquet séparé:

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

L'objet DealtCards existe indépendamment de la façon dont il est affiche, mais son état peut changer si un utilisateur fait quelque chose sur l'interface graphique. Par exemple, demander à être "frappé". Vraisemblablement, il pourrait y avoir un bouton pour le faire. La vue est dérivée de votre modèle.

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..}

}

Maintenant, si un joueur décide de frapper, son objet DealtCards change. Nous voulons donc implémenter une manière de mettre à jour votre modèle. Vous pouvez le faire en utilisant une classe controller. La classe controller implémente l'interface ActionListener. Lorsqu'une action est effectuée (c'est à dire l'utilisateur clique sur "hit" bouton), le contrôleur met à jour le modèle. La vue ne peut donc pas mettre à jour directement le modèle. Il envoie simplement une notification qu'une "action" s'est produite. Toutes les parties intéressées, dans ce cas, notre responsable du traitement, peuvent alors prendre les mesures appropriées.

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();
  }
}

Vous divisez donc votre application en trois couches. Votre modèle contient simplement l'état actuel (ou les données actuelles) et toute validation qui le contourne. Vos classes de vue rendent le modèle de manière appropriée. Toute interaction de l'utilisateur, sur le vue, est géré par le contrôleur, dont la responsabilité est de mettre à jour le modèle.
De cette façon, si vous voulez changer votre vue, (disons utiliser une applet au lieu d'une fenêtre) votre modèle ne s'en soucie pas.
Désolé pour la longue réponse winded, mais j'espère que cela aide un peu!

EDIT: UNE belle MVC explication ici: java / gwt INTERFACE de codage - propre code

 1
Author: Luhar, 2017-05-23 10:27:34