Un problème d'héritage

**Ninored** · 17/02/2014, 18h01

Bonjour, J'ai un petit problème, je présente mon cas:

J'ai trois classes, une nommée MenuPrin, une autre nommée CurseEngine et une autre nommée MenuModule.
Je me dis que CurseEngine va hérité de tous les modules, ici MenuModule. Je met toutes les fonctions de MenuModule en static pour un accès direct sans instancier la classe.

Ensuit, c'est ici que ce pose mon problème, je veux créer une structure qui contient tout les informations du menu et les transmettre à MenuModule, mais je sais pas si il faut déclarer la structure dans les deux classes (MenuPrin et MenuModule).

Schéma d’exécution :

MenuPrin |-----(Demande un menu)-----> CurseEngine |--------(Utilise le module)----->MenuModule

**Neckara** · 18/02/2014, 06h52

Bonjour,

Envoyé par Ninored

Je me dis que CurseEngine va hérité de tous les modules, ici MenuModule.

Trèèès mauvaise idée ça.
Tu va te retrouver avec des risques d'héritage en diamant, des risques de conflits avec les noms de méthodes, et j'en passe.

Envoyé par Ninored

Je met toutes les fonctions de MenuModule en static pour un accès direct sans instancier la classe.

Erreur de conception.
Si toute ta classe est utilisée via des méthodes statiques, c'est qu'il y a un problème.

Déjà, est-ce que tu veux pouvoir ajouter/enlever dynamiquement un module pendant l'exécution de ton programme ?

Là, comme ça je vois trois solutions :

utiliser un système de signaux/slots "à la Qt" ;
utiliser le design pattern singleton pour certains modules mais ce n'est pas une "bonne" solution sauf dans de très rares exceptions (module de logs) ;
une autre solution trop compliquée pour que j'en parle ici (si germinolegrand vois de quoi je parle ).

Après c'est un problème qui est loin d'être évident, j'espère que Koala01 pourra t'apporter quelques éléments de réponses.

Il faudrait que tu revoies ta conception.
Est-ce que tu sais faire des diagrammes de classe UML ?

**Ninored** · 18/02/2014, 13h22

Envoyé par Neckara

Déjà, est-ce que tu veux pouvoir ajouter/enlever dynamiquement un module pendant l'exécution de ton programme ?

Non les modules ne seront pas ajouter/enlever dynamiquement.
Je cherche en fait ici a pouvoir mettre plusieurs Moteurs graphiques, soi un moteur texte (libncurses ici nommé CurseEngine) et un moteur opengl, ou même directX si je fait un portage pour windows.
Je pensais trouver plus simple de faire une sorte de boite qui va contenir toutes mes autres fonctions, pour bien les séparer. Après oui je voie que cela peut faire des problème pour l'héritage

Envoyé par Neckara

Est-ce que tu sais faire des diagrammes de classe UML ?

Je ne sais pas faire de vrai diagrammes UML, je fais simplement des boite représentent mes différentes classes au brouillon (sur un tableau) et j'établis des liens entre elles.

J'aimerai que mon moteur texte puisse utiliser des threads et je me suis dit que CurseEngine va pouvoir, a ma demande, créer des threads pour faire les rendu et laisser la partie logique continuer. Mais je n'en suis pas encore à la ...

**Ninored** · 23/02/2014, 00h21

Je me trouve dans ce cas la:

CurseEngine.hpp

Code cpp :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
// il va inclure tout les modules. Je vais finalement pas créer une classe mais en faire plusieurs petite. 
// (je me suis inspiré de la bibliothèque SFML), J'ai regardé l'un des header.
#include "MenuModule.hpp"

MenuModule.hpp

Code cpp :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
#include <ncurses.h>
class MenuModule
{
 
    public:
        void menuMaker(infoMenu mInfoMenu); // Affiche le menu
 
    private:
// structure posent problème
        struct infoMenu
        {
            int width;
            int height;
            int posX;
            int posY;
            // etc.
        } mInfoMenu;
};

MenuPrin.hpp

Code c++ :

Sélectionner tout - Visualiser dans une fenêtre à part

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
 
#include "CurseEngine.hpp"
 
class MenuPrin
{
 
    public:
// Fonctions constructeurs et d'autres
        void draw();
 
    private:
// La même structure dans MenuModule.hpp
        struct infoMenu
        {
            int width;
            int height;
            int posX;
            int posY;
            // etc.
        } mInfoMenu;
};
 
void MenuPrin::draw()
{
    menuMaker(mInfoMenu);
}

Le compilateur me revoie une erreur comme quoi mInfoMenu n'a pas été déclaré dans le MenuModule, je peux comprendre que le compilateur va différencier les deux structures mais dans ce cas comment faire ? Comment faire connaitre la structure des infos du menu au MenuModule.hpp ?
Je ne voie pas comme faire connaitre cette structure a part la mettre en public dans la classe MenuModule et de faire hériter MenuPrin de celle-ci

**koala01** · 23/02/2014, 06h46

Salut,

On m'a appelé, ben, me voilà... Excusez moi pour le délais de réponse, mais la semaine passée a été particulièrement chargé pour moi

@Ninored Je crois sincèrement que tu pars dans une très mauvaise direction

Si j'ai bien compris l'idée (dis moi si je me trompe), tu voudrais pouvoir créer un menu dont chaque élément ferait appel à un module particulier. Ai-je bon jusque là

D'ici à ce que tu aies le temps de répondre à cette question, je vais faire "comme si" j'étais sur de ta réponse, et continuer mon raisonnement. Dans le pire des cas, les explications que je vais te fournir ici te seront sûrement utiles à un moment ou à un autre

Si j'ai bien compris l'idée, ta classe MenuPrin n'est jamais qu'une classe qui présente un menu qui permettra à l'utilisateur de faire son choix. Cette classe peut, fatalement, contenir plusieurs éléments de menu. En gros, on peut s'attendre à ce qu'elle contienne un élément de menu par choix proposé à l'utilisateur. Cela nous mène tout naturellement à considérer la création d'une classe qui représente "n'importe quel élément du menu". Faisons simple et appelons cette classe MenuElement. Cette classe servirait de classe de base à tous les éléments du menu et pourrait exposer essentiellement deux fonctions dont le comportement devrait être adapté en fonction du type réel de l'élément de menu : print() pour pouvoir afficher le menu et execute() pour pouvoir exécuter la commande qui correspond à chaque élément de menu.

Dans MenuPrin, tu pourrais donc te contenter de ne connaitre l'ensemble des éléments de menu que comme des (pointeurs sur des) objet de type MenuElement. De cette manière, tu pourais envisager d'avoir un code proche de (C++11 inside)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
/* la classe de base commune à tous les éléments du menu
 * 
 * tu remarquera que les fonctions print et execute sont virtuelles pures, ce qui en fait un classe abstraite ;)
 */
class MenuElement{
    public:
        virtual void print() const = 0;
        virtual void execute() const = 0;
        virtual ~MenuElement(){}
};
/* Ta classe menu en elle même */
class MenuPrin{
    public:
        /* permet d'ajouter un nouvel élément de menu */
        void addNewElement(MenuElement * toadd){allMenuElements_.emplace_back(std::unique_ptr<MenuElement>(toadd));}
        void print() const{
             for(auto const & it : allMenuElements_){
                 it.get()->print();
             }
        }
        void execute(size_t toExecute) const{
            allMenuElements_[toExecute].get()->execute();
        }
    private:
    std::vector<std::unique_ptr<MenuElement>> allMenuElements_;
};

Ensuite, il y a le problème des modules qui seront appelés au travers des différents éléments de menu. Les modules ne sont pas des éléments de menu!!! Du simple aspect purement sémantique, cela n'a absolument pas de sens de dire qu'un module EST UN élément de menu. Tu ne peux donc pas envisager de faire hériter un module de MenuElement! Pire encore, chaque module devrait, a priori, être totalement indépendant du reste. Tu ne devrais donc pas avoir une classe ModuleBase, par exemple, qui servirait de classe de base à tes différents modules.

Ainsi, si tu as N modules différents, hé bien, ce sont N classes différentes qui n'ont absolument aucun lien entre elles. Cela prendrait une forme proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
Module1{
    // tout ce qui est utile pour le premier module
};
 
Module2{
    // tout ce qui est utile pour le deuxième module
};
...
ModuleN{
    // tout ce qui est utile pour le Nième module
};

Par contre, je t'ai fait remarquer que MenuElement était une classe abstraite car les fonctions print et execute sont des fonctions virtuelle pures. Cela implique que tu devras, effectivement avoir des classes dérivées de MenuElement. Mais la différence par rapport à ce que tu envisages, c'est que ce ne sont pas des modules. Ce sont des éléments de menu qui utilisent chacun un module spécifique. Cela pourrait donc prendre la forme de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
MenuForModule1 : public MenuElement{
    public:
        void print() const{
            // affichage spécifique pour le module1
        }
        void execute() const{
            // exécution spécifique pour le module1
        }
    private:
        Module1 module_;
};
MenuForModule2 : public MenuElement{
    public:
        void print() const{
            // affichage spécifique pour le module2
        }
        void execute() const{
            // exécution spécifique pour le module2
        }
    private:
        Module2 module_;
};
/* ...*/
 
MenuForModuleN : public MenuElement{
    public:
        void print() const{
            // affichage spécifique pour le moduleN
        }
        void execute() const{
            // exécution spécifique pour le moduleN
        }
    private:
        ModuleN module_;
};

Et, à chaque fois que tu créeras un module complémentaire, tu créera une nouvelle classe dérivée de MenuElement qui l'utilisera "comme il doit être utilisé"

De cette manière, tu pourras faire évoluer ton application strictement à ta guise, en évitant de te retrouver avec des hiérarchies de classes dans lesquelles certains héritages seraient aberrants

**Iradrille** · 23/02/2014, 07h54

Ou la version sans héritage.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
class MenuElement {
public:
	MenuElement(const std::string& name, std::function<void()> exec):
		m_name(name), m_execute(std::move(exec))
	{ }
	void print() const { std::cout << m_name << std::endl; }
	void execute() const { m_execute(); }
private:
	std::function<void()> m_execute;
	const std::string m_name;
};
 
class MenuPrin{
public:
	void addNewElement(const std::string& name, std::function<void()> exec) {
		m_allMenuElements.emplace_back(name, std::move(exec));
	}
	void print() const {
		for(auto const & it : m_allMenuElements) {
			it.print();
		}
	}
	void execute(size_t toExecute) const {
		m_allMenuElements[toExecute].execute();
	}
private:
	std::vector<MenuElement> m_allMenuElements;
};

L'utilisation est identique

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
struct Module1 { void run() { std::cout << "module1\n"; } };
struct Module2 { void run() { std::cout << "module2\n"; } };
 
MenuPrin menu;
Module1 mod1;
Module2 mod2;
menu.addNewElement("module 1", [&mod1]() { mod1.run(); });
menu.addNewElement("module 2", [&mod2]() { mod2.run(); });
 
menu.print();
menu.execute(0);
menu.execute(1);

**imperio** · 23/02/2014, 06h04

Envoyé par Neckara

Erreur de conception.
Si toute ta classe est utilisée via des méthodes statiques, c'est qu'il y a un problème.

C'etait pour ce cas particulier ou de maniere generale ? Si c'est le deuxieme cas je ne suis pas de ton avis car il y a des fois ou ca offre un sacre confort.

Un problème d'héritage

C++

Vue hybride

Discussions similaires

Partager

Partager