IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++ Discussion :

Comception demineur en c++


Sujet :

C++

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre Expert
    Avatar de Mehdi Feki
    Profil pro
    Inscrit en
    Décembre 2004
    Messages
    1 113
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France

    Informations forums :
    Inscription : Décembre 2004
    Messages : 1 113
    Par défaut Comception demineur en c++
    salut tout le monde


    Je suis entrain de creer un jeu de demineur.

    J'ai preparé toutes mes classes Case, Matrice et Jeu.

    Choisi la bibliotheque sdl pour l'implementation graphique. Le probleme est que le code graphique ne doit pas etre integré dans ces classes ( soit disant dites objets metiers ). Que faire ???

    La premiere idée que j'ai eu est de creer des classes graphiques qui heritent directement de leurs classes respectives .

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
     
    class CaseGraphique : public Case
    {
    }
     
    classe MatriceGraphique : public Matrice
    {
    }
    Maintenant le pobleme qui se pose est la relation entre MatriceGraphique et CaseGraphique. Aucune !!!!!

    Je ne peut pas pointé les CaseGraphique dans MatriceGraphique parceque deja la class Matrice pointe sur les differents objets Cases redendance !!!

    Merci d'avance

  2. #2
    Membre chevronné
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Décembre 2004
    Messages
    304
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : Tunisie

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : Décembre 2004
    Messages : 304
    Par défaut
    tu devrait pensé autrement!!
    une classe abstraite pour l'affichage dont tu derive 2 autre classes : l'une pour les cases, l'autre pour la matrice!

  3. #3
    Membre Expert
    Avatar de Mehdi Feki
    Profil pro
    Inscrit en
    Décembre 2004
    Messages
    1 113
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France

    Informations forums :
    Inscription : Décembre 2004
    Messages : 1 113
    Par défaut
    je n'ai pas compris ta reponse
    peux-tu etre plus clair !!!

    pourquoi abstraites ??
    En plus je ne dois pas changer le code des classes matrice et case pour qu'ellent herite de ta classe affichage

    merci comme meme

  4. #4
    Membre chevronné
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Décembre 2004
    Messages
    304
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : Tunisie

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : Décembre 2004
    Messages : 304
    Par défaut
    y aura pa d'heritage!
    par exemple un exemple :
    pour afficher une case:
    tu a dans ta classe GraphicCase une méthode Affiche(Case UneCase)
    pour afficher ta matrice, tu aura certainement besoin de la classe GrapicCase puisque ta matrice est composé de Case...

  5. #5
    Membre Expert
    Avatar de xavlours
    Inscrit en
    Février 2004
    Messages
    1 832
    Détails du profil
    Informations forums :
    Inscription : Février 2004
    Messages : 1 832
    Par défaut
    A priori lorsqu'on sépare les classes graphiques des classes "applicatives", on est souvent obligé de mettre de la "redondance" (moi, des references dans tous les sens, ca ne me gene pas tant que les informations ne sont pas dupliquees).
    De plus, il faut forcément des liens entre ta matrice graphique et les cases (ses sous composants). Si tu ne les définis pas toi, le GUI en aura de toute facon.
    La seule redondance que tu puisse éviter (à mon humble avis) c'est de mettre un pointeur dans les Cases Graphiques vers les "cases". Tu peux l'éviter en mettant un accesseur dans ta classe Matrice qui sera appelé par ta classe MatriceGraphique pour lire les attributs des objets Cases. Tu auras un truc du genre :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    void MatriceGraphique::dessiner()
    {
      for(//parcours des cases)
        CaseGraphique cg = CaseGraphique(case); // tu recuperes les parametres utiles dans Case
        cg.dessiner(//parametres utiles provenant de Matrice ou MatriceGraphique);
    }
    [edit] faudra que j'evite de faire autre chose quand je poste un message, j'arrive souvent apres la bataille !!
    "Le bon ni le mauvais ne me feraient de peine si si si je savais que j'en aurais l'étrenne." B.V.
    Non au langage SMS ! Je ne répondrai pas aux questions techniques par MP.
    Eclipse : News, FAQ, Cours, Livres, Blogs.Et moi.

  6. #6
    Membre Expert
    Avatar de Mehdi Feki
    Profil pro
    Inscrit en
    Décembre 2004
    Messages
    1 113
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France

    Informations forums :
    Inscription : Décembre 2004
    Messages : 1 113
    Par défaut
    la bataille n'est pas encore finie

    merci pour ta reponse

    Je suis tout a fait daccord avec toi !! Je suis pres de faire de la redondance sur ce point je n'ai aucun probleme

    Le probleme de redondance que j'ai presenté dans le 1er poste n'existe que dans le cas si j'utilise l'heritage . Je m'explique encore

    La class matrice contient un tableau 2 dimensions de Cases *

    Si je cree Une class MatriceGraphique qui herite de Matrice les (n*m) objets cases encapsulé dans la Class Matrice vont etre instanciés lors de l'appel du constructeur de MatriceGraphique . mais moi je veux manipuler des CasesGraphiques vous voyez un peu la confusion !!!

    Apparament l'heritage n'est pas une tres bonne solution pour ce cas !!! C'est ce que je constate ..

  7. #7
    Membre Expert
    Avatar de Mehdi Feki
    Profil pro
    Inscrit en
    Décembre 2004
    Messages
    1 113
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France

    Informations forums :
    Inscription : Décembre 2004
    Messages : 1 113
    Par défaut
    Donc puisque je n'ai pas encore recu de reponse concraite j'ai obté pour cette solution

    Une classe jeu qui gere tous ce qui est evenement !!
    une classe affichage qui a une vue sur les classes Case et Matrice et qui tout simplement affiche !!

    Ce n'est pas trop beau parceque la classe Affichage a un access aux etats de matrice et case mais bon !!!

  8. #8
    Membre Expert
    Avatar de xavlours
    Inscrit en
    Février 2004
    Messages
    1 832
    Détails du profil
    Informations forums :
    Inscription : Février 2004
    Messages : 1 832
    Par défaut
    Ok, alors si tu fais de l'héritage, oui il y a redondance : ton objet Matrice et ton objet MatriceGraphique auront des attributs dupliqués .
    Je te conseille fortement de faire de la délégation, justement en placant des accesseurs dans Matrice pour toutes les infos dont aura besoin ton objet MatriceGraphique.
    Ton objet MatriceGraphique aura un pointeur sur ton objet Matrice, et appellera les accesseurs (getters) a chaque fois qu'il en aura besoin.
    Si tu fais de l'héritage, ta classe MatriceGraphique encapsule les données graphiques et aussi les données "de metier". Tu ne réponds donc pas au choix que tu as fait au début, qui me semble très bon.
    Au niveau de l'héritage, tes classes MatriceGraphique et CaseGraphique hériteront forcément d'une classe ComposantGraphique du GUI. En venant de Java, je suis pas trop habitué à l'héritage multiple et je l'évite autant que possible (mais je ne veux pas lancer un troll...). Les liens entre objets graphiques et objets metiers devraient etre des liens de délégation a mon humble avis.
    Voila, j'espère t'avoir convaincu !
    [edit] Le choix que tu as fait est bon aussi, tu ne peux pas afficher des cases dont tu ne connais pas l'état. Simplement place des getters, et pas des setters. Comme ca la classe Affichage pourra lire mais pas modifier les états.
    "Le bon ni le mauvais ne me feraient de peine si si si je savais que j'en aurais l'étrenne." B.V.
    Non au langage SMS ! Je ne répondrai pas aux questions techniques par MP.
    Eclipse : News, FAQ, Cours, Livres, Blogs.Et moi.

Discussions similaires

  1. Demineur erreur de segmentation.
    Par -ezano- dans le forum C
    Réponses: 13
    Dernier message: 16/12/2009, 20h15
  2. Comception Interface webservice
    Par DOUDOUX11 dans le forum Méthodes
    Réponses: 1
    Dernier message: 28/01/2009, 16h21
  3. Pb du demineur
    Par mcalus dans le forum Tkinter
    Réponses: 10
    Dernier message: 26/01/2009, 14h52
  4. [LG]Démineur pascal...
    Par youngeikichi dans le forum Langage
    Réponses: 10
    Dernier message: 29/01/2005, 18h16

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo