mvc en mode console

Version imprimable

01/10/2013, 12h13
PilloBuenaGente

mvc en mode console
Bonjour,

Serait-il judicieux pour un programme en mode console d'appliquer le mvc ainsi ? :
Code:

1 2 3 4 5 6 Model model; View view; Controler controler; while( model.run()) view.print( model.work( controler.recive()));
( print ne renvoie rien, work revoit un vecteur de string, et recive revoit une string )

Je pense que, à défaut de perdre en flexibilité, je vais gagner en organisation. Mais je me trompe peut être.

Qu'en pensez vous ?
01/10/2013, 12h18
Astraya

Bonjour,

Pour un programme en mode texte ( console ) je doute que le MVC soit approprié. Quel est ton objectif final en faisant ça?
01/10/2013, 12h32
white_tentacle

C’est toujours une bonne idée de séparer l’interface (la vue) du cœur du programme (le modèle et le contrôleur).

Par contre, je ne comprends pas ta boucle. model.work, ça me hérisse : le traitement doit se faire au niveau du contrôleur (qui agit sur le modèle), pas du modèle.

Idem pour controller.receive --> c’est plutôt la vue qui reçoit des commandes, qu’elle transmet ensuite au contrôleur (qui est indépendant d’une vue particulière).

En fait, ce serait plutôt une boucle du genre:

Code:

1
2
3
4
5
6
7
8
9
10
11
Model model;
View view;
Controler controler;
 
do
{
	view.display(model);
	Input input=view.read();
	controler.work(model, input);
}
while(!controller.quitting);

01/10/2013, 17h46
koala01

Salut,

Il est toujours utile de découper très finement les différents éléments et de prévoir de travailler selon le principe MVC.

Et je vais même aller plus loin : si tu peux travailler avec des abstractions pour tes classes View, (Input, introduite par Médinoc) et Controler, c'est encore mieux.

Sait-on jamais : As-tu la certitude absolue que ton programme restera en ligne de commande "ad vitam" :question:

On ne connait rien de ton projet, et l'on ne saura de toutes manières pas répondre à ta place, mais, à moins que tu ne crées un service (quelque chose qui tourne en tâche de fond), il me semble difficile d'avoir une telle certitude... Et encore! ;)

Si, un jour, tu décides de rajouter une interface graphique à ton programme, et d'utiliser non plus le clavier mais les événements souris (entre autres) pour introduire tes commandes, tu seras bien content d'avoir utilisé une abstraction pour ta vue, ton contrôleur et ton système d'entrées car les adaptations ne signifieront pas que tu dois "tout casser" pour venir les greffer ;)
01/10/2013, 20h39
PilloBuenaGente

Merci pour votre temps !!

Astraya -> L'objectif était d'avoir une forte contrainte d'organisation pour m'aider à construire le tout.
( Plus j'en apprends sur le c++, moins je vois comment organiser mes affaires.. La digestion m'est longue. )

white_tentacle -> J'y vois plus clair sur le MVC.

Médinoc ->Très clair maintenant !
On peut donc avoir un main ainsi ?! Ni plus ni moins ?!

koala01 -> La modularité n'était pas mon objectif premier mais en effet, ça peut s’avérer utile ! ( Le jour ou je me lancerais sur Qt )

Citation:

si tu peux travailler avec des abstractions pour tes classes View, (Input, introduite par Médinoc) et Controler, c'est encore mieux.

Edit~~Pour, par exemple, pouvoir switcher dynamiquement d'un contrôleur à un autre ?~~Désolé :oops:
01/10/2013, 22h41
koala01

Citation:

Envoyé par PilloBuenaGente

koala01 -> La modularité n'était pas mon objectif premier mais en effet, ça peut s’avérer utile ! ( Le jour ou je me lancerais sur Qt )Edit~~Pour, par exemple, pouvoir switcher dynamiquement d'un contrôleur à un autre ?~~Désolé :oops:

Ce n'est pas grave, mais je répond quand même, nah :D

Il y a de ca, mais il y a surtout le fait que ton abstraction te facilitera énormément la tâche si tu décides un jour de passer à Qt, ou d'abandonner Qt au profit de n'importe quel autre framework adapté à tes besoins ;)

Si l'on y réfléchit bien, n'importe quelle application un tantinet interactive va, essentiellement, devoir répondre à une série de commandes introduites par l'utilisateur.

Classiquement, il sera de la responsabilité "du système d'entrées" (quel qu'il soit) de déterminer "ce que veut l'utilisateur" en introduisant une information donnée.

Qu'il s'agisse ici d'une chaine de caractères comme "déplace A3 en D88" ou du clique sur un bouton ou que sais-je n'a pas énormément au niveau de l'abstraction, ce qui importe c'est que "n'importe quel système d'entrée" soit en mesure d'émettre "n'importe quelle commande qu'il est en mesure d'avoir compris".

Une commande aura -- peut-être, mais pas forcément (je pense à la commande d'aide par exemple) -- un impact sur tes données métier, et -- beaucoup plus certainement -- un impact "visuel"

La manière dont le "rendu" de la commande est effectué dépend essentiellement de la manière dont tu as envisagé ton système "de sortie" évidemment, mais, si tu peux réduire la notion de "système d'affichage" à une abstraction de type "render", tu te fous pas mal que ce rendu soit fait sous la forme de "Ajout de XXX à la liste Y" ou que cela se fasse sous la forme de l'ajout d'une ligne dans un "widget" quelconque ;)

Ce qui importe, c'est que chaque commande provoque une réaction visuelle qui puisse rassurer l'utilisateur sur le fait qu'elle a bel et bien été prise en compte ;)

Tu l'auras compris, le "système d'entrées" et le "système de sortie" seront très fortement corrélés: si tu es en mode console uniquement le premier manipulera le "flux d'entrées standard" et le second le "flux de sortie standard", alors que si tu utilise Qt (ou n'importe quel autre framework similaire), ben, tu disposeras de tout l'éventail de possibilités proposées par ton framework pour l'un comme pour l'autre ;).

Alors, le "fin du fin" serait de se dire que, de toutes manières, il n'y a que les commandes que le système d'entrée est en mesure de comprendre qui devront avoir un équivalent visuel, et de trouver le moyen de faire en sorte de ne pas obliger le système de sortie à prendre en charge toutes les commandes possibles alors que certaines ne sont peut être même pas prises en compte par le système d'entrées auquel il est corrélé :D.

C'est tout à fait possible au prix d'une ou deux abstractions supplémentaires, mais c'est un autre débat :D

Citation:

Envoyé par PilloBuenaGente

Médinoc ->Très clair maintenant !
On peut donc avoir un main ainsi ?! Ni plus ni moins ?!

Il est même très largement conseillé d'avoir une fonction principale (quel que soit le langage visé) la plus petite possible :D

Quel que soit le langage, si tu peux avoir une fonction principale du genre de
Code:

1 2 3 4 5 6 int main(){ init(); execute(); destroy(); return 0; }
C'est l'idéal ;)

Maintenant, dans une approche OO, étant donné qu'on va essayer de respecter le RAII (et son homologue RFID), cela pourrait prendre la forme de
Code:

1 2 3 4 5 int main(){ Game game; // on estime que le constructeur de game fait tout le nécessaire :D game.execute(); // toute la durée du jeu se retrouve ici return 0; } // le destructeur de Game fait le ménage ;)
Pourquoi en faudrait-il d'avantage :question:

03/10/2013, 19h04
PilloBuenaGente

J'ai rayé la question car j'ai confondu le controler et le controleur..
Mais la question a quand même été comprise et la réponse était bien celle que j’espérais :ccool:

Merci pour ces précision supplémentaire !

Je vais expérimenter tout ça.
Je vous dit donc à bientôt !:)

Comme promis me revoilà :D

(La lecture du code n'est pas nécessaire pour comprendre mes requêtes)
J'obtiens ceci en espérant avoir respecter les règles.

main.cpp

Code:

1
2
3
4
5
6
7
8
#include "Program.h"
 
int main()
{
    Program program;
     program.execute();
    return 0;
}

Program.h

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
#ifndef PROGRAM_H_INCLUDED
#define PROGRAM_H_INCLUDED
 
#include "Model.h"
#include "View.h"
#include "Controler.h"
 
//===============================
// CLASS PROGRAM
//-------------------------------
class Program
{
public:
    // DISABLE COPY/AFFECTATION
    Program( const Program& ) = delete;
    Program& operator =( const Program& ) = delete;
 
    // CONSTRUCTOR/DESTRUCTOR
    Program();
    ~Program();
 
    // MAIN LOOP
    void execute();
 
private:
    // MODIF VIEW/CONTROLER
    void                                    update( const PageId page_id );
    template< typename ViewType > void      change_view() { delete view_p; view_p = new ViewType; }
    template< typename ControlerType > void change_controler() { delete controler_p; controler_p = new ControlerType; }
 
    // MEMBERS
    Model       model_;
    View*       view_p;
    Controler*  controler_p;
};
 
#endif // PROGRAM_H_INCLUDED

Program.cpp

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
#include "Program.h"
 
using namespace std;
#include <string>
 
//===============================
// PROGRAM CONSTRUCTOR/DESTRUCTOR
//-------------------------------
Program::Program()
{
    view_p      = new View_Summary;
    controler_p = new Controler_Summary;
}
Program::~Program()
{
    delete view_p;
    delete controler_p;
}
//===============================
// PROGRAM MAIN LOOP
//-------------------------------
void Program::execute()
{
    while( model_.program_life())
    {
        view_p->display( model_ );
        Input input = view_p->read();
        controler_p->work( input, model_ );
        update( model_.page_id());
    }
}
//===============================
//// PROGRAM MODIF VIEW/CONTROLER
//-------------------------------
void Program::update( const PageId page_id )
{
    switch( page_id )
    {
    case PROGRAM_SUMMARY:
        change_view< View_Summary >();
        change_controler< Controler_Summary >();
        break;
    case PROGRAM_OPTIONS:
        change_view< View_Options >();
        change_controler< Controler_Options >();
        break;
    }
}

Model.h

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
#ifndef MODEL_H_INCLUDED
#define MODEL_H_INCLUDED
 
//===============================
// CLASS PAGE_ID
//-------------------------------
enum PageId : char
{
    PROGRAM_SUMMARY,
    PROGRAM_OPTIONS
};
//===============================
// CLASS MODEL
//-------------------------------
class Model
{
public:
    // INITIALISATION
    Model() : program_life_( true ), page_id_( PageId::PROGRAM_SUMMARY ) {}
 
    // CONSTANT FUNCTIONS
    const bool program_life() const { return program_life_; }
    const PageId page_id() const { return page_id_; }
 
    // MODIF FUNCTIONS
    void program_exit() { program_life_ = false; }
    void page_move( const PageId page_id ) { page_id_ = page_id; }
 
private:
    // MEMBERS
    bool program_life_;
    PageId page_id_;
};
 
#endif // MODEL_H_INCLUDED

Controler.h

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
#ifndef CONTROLER_H_INCLUDED
#define CONTROLER_H_INCLUDED
 
#include "Model.h"
#include "Input.h"
 
//===============================
// CLASS CONTROLER VIRTUAL
//-------------------------------
class Controler
{
public:
    // VIRTUAL DESTRUCTOR
    virtual ~Controler() {}
 
    // WORK FUNCTION
    virtual void work( const Input& input, Model& model ) = 0;
};
//===============================
// CONTROLER SUMMARY
//-------------------------------
class Controler_Summary : public Controler
{
    void work( const Input& input, Model& model )
    {
        if( input == "0" )
            model.program_exit();
        else if( input == "1" )
            model.page_move( PageId::PROGRAM_OPTIONS );
    }
};
//===============================
// CONTROLER OPTIONS
//-------------------------------
class Controler_Options : public Controler
{
    void work( const Input& input, Model& model )
    {
        if( input == "0" )
            model.page_move( PageId::PROGRAM_SUMMARY );
    }
};
 
#endif // CONTROLER_H_INCLUDED

View.h

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
#ifndef VIEW_H_INCLUDED
#define VIEW_H_INCLUDED
 
#include "Model.h"
#include <string>
 
#include <iostream>
 
//===============================
// CLASS VIEW VIRTUAL
//-------------------------------
class View
{
public:
    // VIRTUAL DESTRUCTOR
    virtual ~View() {}
 
    // DISPLAY AND READ FUNCTIONG
    virtual void display( const Model& model ) const = 0;
    const std::string read() { std::string string; std::getline( std::cin, string ); return string; }
};
//===============================
// VIEW SUMMARY
//-------------------------------
class View_Summary : public View
{
public:
    void display( const Model& model ) const { std::cout << "Summary ..." << std::endl; }
};
//===============================
// VIEW OPTIONS
//-------------------------------
class View_Options : public View
{
public:
    void display( const Model& model ) const { std::cout << "Option ..." << std::endl; }
};
 
#endif // VIEW_H_INCLUDED

Input.h

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
#ifndef INPUT_H_INCLUDED
#define INPUT_H_INCLUDED
 
#include <string>
 
//===============================
// CLASS INPUT
//-------------------------------
class Input
{
public:
    // AFFECTATION
    Input( const std::string string ) : string_( string ) {}
    Input               operator =( const std::string string ) { return Input( string ); }
 
    // string ENTERED
    const std::string&    string() { return string_; }
 
    // string CONTROL
    const int           size() const { return string_.size(); }
    const bool          operator ==( const std::string& string ) const { return( string_ == string ); }
 
private:
    // MEMBER
    std::string string_;
};
 
#endif // INPUT_H_INCLUDED

Cependant deux points me dérangent :

-Je vais avoir des données propres au mode console dans le model (La liste d'id des menus, des informations pour l'affichage de liste sur plusieurs pages, ex..) Cette classe à t-elle le devoir de savoir cela ?
Je peux les regrouper dans une sous classe de model, mais ça ne me semble pas parfait..

-Deuxièmement je ne vois pas comment rendre ma classe Input abstraite; le type de retour pourra être différent, dans ce cas la virtualité ne fonctionne plus.
Peut être avec des templates ?!

10/10/2013, 14h50
Kaamui
Citation:
Envoyé par Médinoc

En fait, ce serait plutôt une boucle du genre:

Code:

1 2 3 4 5 6 7 8 9 10 11 Model model; View view; Controler controler; do { view.display(model); Input input=view.read(); controler.work(model, input); } while(!controller.quitting);
Moi j'aurais plutôt dit :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 Model model; View view; Controler controler; while (view.isOpen()) { Input input; if (view.getEvent(input)) controller.work(input, model); view.diplay(model); }
Ce qui revient presque au même je te l'accordre :)

Sinon pour le code, je ne pige pas pourquoi tu as un controller.work suivi d'un model.update ?

Pour les premières questions, ton model peut contenir la liste de tes id, s'il s'agit d'une espèce de type énuméré c'est tout à fait recevable en tant que donnée du modèle (personnellement j'ai tendance à considérer les models dans un MVC comme des classes de données brutes plus que des classes de services). Après si tu as une liste de choses qui concernnent toute ton application sans forcément concerner ton modèle en particulier, tu peux passer par un bete fichier plat de configuration, ou une classe de base pour que ce soit conceptuellement plus juste en terme de vision humaine.

Pour ta deuxième question oui si tel est ton besoin les templates ou l'héritage peuvent etre emplyés à cela.
10/10/2013, 15h01
PilloBuenaGente

Lors du changement de page, je change à la fois le contrôleur et la vue, je ne peux donner cette charge au contrôleur ?!

Citation:

Pour les premières questions, ton model peut contenir la liste de tes id, s'il s'agit d'une espèce de type énuméré c'est tout à fait recevable en tant que donnée du modèle (personnellement j'ai tendance à considérer les models dans un MVC comme des classes de données brutes plus que des classes de services). Après si tu as une liste de choses qui concernnent toute ton application sans forcément concerner ton modèle en particulier, tu peux passer par un bete fichier plat de configuration, ou une classe de base pour que ce soit conceptuellement plus juste en terme de vision humaine

Merci pour ces précisions. Je vais peut être rajouter un accès à une database (données brut) via mon modèle.

Citation:

(personnellement j'ai tendance à considérer les models dans un MVC comme des classes de données brutes plus que des classes de services)

Mais, comme le disait Koala01, si j'implante ces services dans le contrôleur, cela impliquera de retoucher aux algorithmes d'accès pour changer d'interface.
10/10/2013, 15h06
Kaamui

Le controlleur est justement là pour servir de mutateur au modèle associé. Du coup ton model.update peut être fait dans ta méthode work.
10/10/2013, 15h18
PilloBuenaGente

Citation:

Le controlleur est justement là pour servir de mutateur au modèle associé. Du coup ton model.update peut être fait dans ta méthode work.

C'est pas mal ça ! Et donc définir mes classes filles de view et controler dans le model !
10/10/2013, 15h39
Kaamui
Après je suis également d'accord avec Koala01 donc il y a peut-être une impasse dans mes propos que je ne vois pas, mais pour moi, l'un n'empêche pas l'autre.
1. Ta vue gère l'affichage et les évènement
2. Ton controlleur gère toutes les actions : pour chaque évènement au moins une méthode, et un controlleur par ... ce que tu veux :) => tu organise tes vues par ensemble et tu ne fais qu'un gros controlleur ou tu fais un controlleur par vue peu importe
3. Ton model contient les données, brutes.
Pour moi (et c'est peut-être là que je me trompe) :

Si tu change d'avis et que tu veux passer de console à Qt, le seul impact est sur ta vue => 'affichage' + 'events'

Process :
- entrée clavier ou souris
- récupération de l'évènement par ta vue (cin ou QEvent)
- appelle par ta vue d'une méthode d'un controlleur correspondant
- actions par le controlleur sur le model
- retour du controlleur vers une vue (redirection ou retour de resultat)
- affichage
A la rigueur tu peux même ajouter une abstraction supplémentaire à ta vue pour faciliter le changement potentiel de manière d'afficher/gérer

Koala01 dis moi où je me plante si tel est le cas ;)
10/10/2013, 15h55
PilloBuenaGente

(J’espère au moins ne pas avoir mal interprété les propos de Koala01 :oops:)

Citation:

Process :

entrée clavier ou souris
récupération de l'évènement par ta vue (cin ou QEvent)
appelle par ta vue d'une méthode d'un controlleur correspondant
actions par le controlleur sur le model
retour du controlleur vers une vue (redirection ou retour de resultat)
affichage

Et oui cette méthode m'a l'air de tout à fait fonctionner !
Je vais tester dans ce sens !

Merci !!