Polymorphisme en évitant les casts

Version imprimable

09/10/2011, 13h21
dagera

2 pièce(s) jointe(s)

Polymorphisme en évitant les casts

Bonjour,

Je me lance dans la conception d'un nouveau soft là, donc j'ai champ libre pour son architecture. Il y a un problème auquel j'ai été confronté plusieurs fois, c'est l'utilisation de l'héritage et du polymorphisme ... Je trouve des solutions qui, d'un point de vue UML, sont propre (enfin, je pense ;) ), mais qui une fois amené au C++ demandent beaucoup trop de de casts à mon gout.

J'ai deux exemples en tête :

1. Deux classes d'interfaces, fortement liées entre elles, qui ont toutes deux un système d'héritage.

Je prend l'exemple d'une classe de traitement, et sa classe de configuration.
J'ai fait un petit diagramme UML pour que ça soit plus clair :

http://www.developpez.net/forums/att...1&d=1318158598

Dans cette exemple, je sais d'avance que la classe TraitementVideo, aura un objet de type Configuration Video, de même pour l'audio. Par contre, la donnée sera stocké sous forme de TraitementConfigurationInterface, ce qui m'oblige à faire un cast à chaque fois. Au niveau performance ce n'est pas très grave, vu qu'il s'agira d'un static_cast, mais je trouve pas ça super propre.
J'ai pensé à utiliser des templates sinon, qui seront spécifié par les classes filles lors du constructeur, mais ça m'a pas l'air dans la philosophie du polymorphisme ...

2. Mon second problème concerne le polymorphisme pour un objet recu en parametre d'une fonction.

Là en encore, un petit exemple d'héritage pour que ça soit clair :

http://www.developpez.net/forums/att...1&d=1318158972

Si l'on reprend mes classes de traitement décrite plus haut, ces dernières vont avoir une méthode de type "computeMessage( const Message & msg)".
Le problème, c'est que les messages dans mon application vont suivre un chemin de classes de traitement définit à la configuration.
Ces classes de traitement devront spécifié les messages, du coup je pense être obligé de faire un dynamic_cast pour m'assurer de recevoir le bon type de message. Le problème c'est que les dynamic_cast, niveau performance ca me rebute un peu, mais je ne suis pas sur d'avoir le choix là dessus ... :/
Comme il ne s'agit pas d'une application destiné au grand public, les plantages pour mauvaise configuration sont tolérés. Est il possible de faire un static_cast et de trouver un moyen de lever une exception sur plantage du à un mauvais type d'objet reçu ?
De cette manière on peut utiliser des static_cast ce qui nous fait gagner en performance, et en cas de plantage la source d'erreur sera rapide à trouver.
09/10/2011, 13h58
yan

:koi:
Pourquoi tu veux faire des cast partout???
09/10/2011, 14h04
dagera

Dans les exemples données, ca serait pour que la classe TraitementVideo puisse acceder aux paramètres qui lui sont propre de la classe Configuration vidéo, et pour que les méthodes computeMsg puisse accèder aux données propres aux messages vidéos.
(Les diagrammes avec l'audio / video ne sont qu'un exemple pour illustrer, mon programme ne traite pas du tout de ça ;) )
09/10/2011, 14h24
yan

:koi: dsl, mais je ne comprend où tu as besoin de faire un cast...
Peux tu mettre une petit code d'exemple?

Voilà un petit exemple :

Messages :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
class Message
{
public:
	unsigned long getLength() const;
	unsigned char* getBuffer() const;
 
protected:
	unsigned char* _buffer;
	unsigned long _length;
};
 
class MessageVideo : public Message
{
public:
	unsigned short getStreamType() const;
};

Pour la configuration :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
class TraitementConfigurationInterface
{
public:
	virtual bool loadParametersFromFile( const std::string &confFilePath) = 0;
};
 
class ConfigurationVideo : public TraitementConfigurationInterface
{
 
public:
	virtual bool loadParametersFromFile( const std::string &confFilePath);
 
	unsigned float getFrameRate() const;
 
private:
	unsigned float _frameRate;
 
};

Pour la classe de traitements (qui contient les casts) :

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
 
 
class TraitementInterface
{
public:
	virtual bool computeMessage(const Message * msg) = 0;
 
protected:
 
	TraitementConfigurationInterface* _myConf;
 
};
 
class TraitementVideo : public TraitementInterface
{
public:
	inline virtual bool computeMessage(const Message * msg)
	{
		MessageVideo* messageReceived = dynamic_cast<MessageVideo*> (msg);
		if(messageReceived)
		{
			std::cout<<"Mauvais type de message recu"<<std::endl;
			return false;
		}
 
		if( messageReceived->getStreamType() == META_DATA )
		{
			// Traitement ...
		}
 
		// .....
 
		if( (static_cast<ConfigurationVide*>(_myConf))->getFrameRate() < 30.0 )
		{
			// Traitement
		}
		else
		{
			// Autre traitement
		}
 
		// ....
 
		return true;
	}
};

09/10/2011, 20h34
yan

Code:

MessageVideo* messageReceived = dynamic_cast<MessageVideo*> (msg);

pour le dynamic_cast, ca ne me choque pas. A la limite tu pourrais ajouter un id permettant de savoir ce qu'est msg sans utiliser le dynamic_cast et utiliser static_cast.

Code:

(static_cast<ConfigurationVide*>(_myConf))

Par contre celui là je ne le comprend pas.

J'ai l'impression que TraitementInterface, TraitementConfiguratioInterface sont trop générique.
Pourquoi des classes commune pour de la video et de l'audio?
09/10/2011, 21h10
dagera

J'ai fait une erreur de frappe dans le static_cast, il s'agit d'un ConfigurationVideo* (enfin je pense que tu l'avais compris ^^)
Pour les classes de configuration je pense avoir mal choisi l'exemple en fait ... ;) Effectivement là ça aurait pas trop de sens.
Dans mon cas, les classes de traitement ont des traitements en commun, dont certains traitement qui ont besoin d'attribut présents dans la classe de configuration mère. Cependant, les classes de traitement fille font aussi des traitements qui leur sont propre, et qui ont besoin d'informations qui sont stocké dans la classe de configuration fille qui leur est dédiée, d'où le cast.

Ta solution avec les ID a l'air bien ;) C'est pas trop "artisanal" par contre ? Mais c'est vrai qu'en y réfléchissant le dynamic_cast n'a pas l'air trop méchant, surtout qu'il n'y aurait pas une très grande hiérarchie dans l'héritage.
09/10/2011, 21h47
yan

Citation:

Dans mon cas, les classes de traitement ont des traitements en commun, dont certains traitement qui ont besoin d'attribut présents dans la classe de configuration mère. Cependant, les classes de traitement fille font aussi des traitements qui leur sont propre, et qui ont besoin d'informations qui sont stocké dans la classe de configuration fille qui leur est dédiée, d'où le cast.

Y as t'il un réelle intérêt à TraitementConfigurationInterface?? C'est ce qui me gêne le plus. Pour moi ce ne devrais pas être quelques chose de générique et unique pour chaques classes.

Citation:

Ta solution avec les ID a l'air bien ;) C'est pas trop "artisanal" par contre ?

Ca dépend. Tu peux trouver cela dans Qt avec QVariant ou avec les QEvents.
Je ne connais pas le coût ajouté par le dynamic_cast
09/10/2011, 22h08
JolyLoic

Je n'ai pas trop le temps de développer, mais dès ton schéma UML, je trouve qu'il y a des faiblesses. Il indique qu'un traitement vidéo peut avoir une configuration audio. Ensuite, définir une classe de base n'a d'intérêt que s'il y a des opérations associés à cette classe. Là, je ne vois pas trop le rôle de TraitementConfigurationInterface.
C'est difficile de parler plus d'un design par écrit, surtout quand on ne connait pas le vrai besoin qu'il peut y avoir derrière. Intuitivement, je dirais que je choisirais probablement soit 2 classes séparées pour les 2 configurations, soit une seul classe totalement générique (qui wrappe une map<Nom, Valeur> de paramètres).

Salut,

Je suis de l'avis de Loïc...

De prime abord, j'aurais tendance à dire qu'il y a peu de chances que tu veuilles manipuler des collections de traitement audio et video mélangés et des collections de configurations audio et video mélangées.

En effet, il y a de fortes chances que le traitement audio soit pris en charge d'un coté tout à fait différent de l'endroit où le traitement video sera pris en charge.

Au pire, tu regroupera les objets responsables de ces deux traitements dans une structure ad-hoc, et, si une fonction doit lancer un traitement video et un traitement audio simultanés, il "suffira" d'appeler les deux successivement ;)

Si vraiment tu veux pouvoir gérer des collections de traitements ou de configurations confondues, tu devrais envisager un pattern "visiteur", avec un petit coup de NVI le traitement étant le visiteur, la configuration étant la visitée.

Cela pourrait prendre une forme proche de
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 49 50 51 class Configuration { public: bool accept(Traitement* tr){return doAccept(*tr);} private: /* par défaut, on renvoie false, pour n'avoir que les traitement ad-hocs * à réimplémenter et à gérer */ virtual bool doAccept(TraitementVideo & ){return false;} virtual bool doAccept(TraitementAudio &){return false;} }; class ConfigurationVideo : public Configuration { private: virtual bool doAccept(TraitementVideo & tr){ tr.visit(*this);} }; class ConfigurationAudio : public Configuration { private: virtual bool doAccept(TraitementAudio & tr){ tr.visit(*this);} }; class Traitement { /* même pas besoin de déclarer visit ici : chaque classe de configuration * qui va appeler la fonction le fera sur une classe particulière :D */ }; class TraitementVideo : public Traitement { public: /* visit n'a même pas besoin d'être virtuelle :D */ bool visit(ConfigurationVideo /* const */ & conf) { /*...*/ } }; class TraitementAudio : public Traitement { public: /* visit n'a même pas besoin d'être virtuelle :D */ bool visit(ConfigurationAudio /* const */ & conf) { /*...*/ } };

10/10/2011, 13h28
Emmanuel Deloget

Mon dieu !

OCP est mort !

:cry:

Plus sérieusement, il te faut revoir cette hiérarchie de classes, parce qu'elle n'est pas maintenable à long terme. Quelques mot-clef qui peuvent t'aider :

* open-close principle
* loi de demeter
* Liskov substitution principle

Il y en a d'autres, mais ceux là peuvent peut-être déjà te permettre de pointer les problèmes de l'architecture que tu proposes.
10/10/2011, 18h56
koala01

Citation:

Envoyé par Emmanuel Deloget

Mon dieu !

OCP est mort !

:cry:

Plus sérieusement, il te faut revoir cette hiérarchie de classes, parce qu'elle n'est pas maintenable à long terme. Quelques mot-clef qui peuvent t'aider :

* open-close principle
* loi de demeter
* Liskov substitution principle

Il y en a d'autres, mais ceux là peuvent peut-être déjà te permettre de pointer les problèmes de l'architecture que tu proposes.

Est-ce à moi que tu en as ou au PO :question:
10/10/2011, 19h04
Emmanuel Deloget

Citation:

Envoyé par koala01

Est-ce à moi que tu en as ou au PO :question:

A personne en particulier, mais c'est le post du PO qui m'a fait réagir :)

Il va vraiment falloir que je suis plus disert sur le contexte de mes prises de parole :)
10/10/2011, 19h10
koala01

Citation:

Envoyé par Emmanuel Deloget

A personne en particulier, mais c'est le post du PO qui m'a fait réagir :)

Il va vraiment falloir que je suis plus disert sur le contexte de mes prises de parole :)

Ceci dit, cela aurait pu être à moi, vu que, même si j'ai commencé par expliquer qu'il ne fallait pas le faire, je lui ai quand même donné une solution qui bafoue au moins les deux premières pour y arriver :aie: :D

Citation:
Envoyé par koala01
Salut,

Je suis de l'avis de Loïc...

De prime abord, j'aurais tendance à dire qu'il y a peu de chances que tu veuilles manipuler des collections de traitement audio et video mélangés et des collections de configurations audio et video mélangées.

En effet, il y a de fortes chances que le traitement audio soit pris en charge d'un coté tout à fait différent de l'endroit où le traitement video sera pris en charge.

Au pire, tu regroupera les objets responsables de ces deux traitements dans une structure ad-hoc, et, si une fonction doit lancer un traitement video et un traitement audio simultanés, il "suffira" d'appeler les deux successivement ;)

Si vraiment tu veux pouvoir gérer des collections de traitements ou de configurations confondues, tu devrais envisager un pattern "visiteur", avec un petit coup de NVI le traitement étant le visiteur, la configuration étant la visitée.

Cela pourrait prendre une forme proche de
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 49 50 51 class Configuration { public: bool accept(Traitement* tr){return doAccept(*tr);} private: /* par défaut, on renvoie false, pour n'avoir que les traitement ad-hocs * à réimplémenter et à gérer */ virtual bool doAccept(TraitementVideo & ){return false;} virtual bool doAccept(TraitementAudio &){return false;} }; class ConfigurationVideo : public Configuration { private: virtual bool doAccept(TraitementVideo & tr){ tr.visit(*this);} }; class ConfigurationAudio : public Configuration { private: virtual bool doAccept(TraitementAudio & tr){ tr.visit(*this);} }; class Traitement { /* même pas besoin de déclarer visit ici : chaque classe de configuration * qui va appeler la fonction le fera sur une classe particulière :D */ }; class TraitementVideo : public Traitement { public: /* visit n'a même pas besoin d'être virtuelle :D */ bool visit(ConfigurationVideo /* const */ & conf) { /*...*/ } }; class TraitementAudio : public Traitement { public: /* visit n'a même pas besoin d'être virtuelle :D */ bool visit(ConfigurationAudio /* const */ & conf) { /*...*/ } };
Est il raisonnable de parler de Multiple dispatch dans le cas présent?