Discussion :

[sinasquax]

Bonjour a tous, je débute en C++ (pas dans le langage mais dans la facon de penser objet) et j'aimerai savoir quelle est la meilleure solution (et pourquoi) de ce probleme :

Une classe abstraite (vehicule par exemple) contient une variable nom et deux classes filles de vehicule (voiture et moto par exemple) doivent avoir leur bon nom, le probleme est qu'il y a beaucoup de facons de l'implementer mais j'aimerai connaitre la meilleure.

Soit :

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
 
class CVehicule
{
public :
 
 CVehicule();
 virtual ~CVehicule();
 
 const std::string &getName (void) const { return this->name; };
 
protected :
 
 void setName (std::string name) { this->name = name; };
 
private :
 std::string name;
};
 
// Avec les classes filles qui utilisent setName pour mettre leur noms

ou bien :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
class CVehicule
{
public :
 
 CVehicule();
 virtual ~CVehicule();
 
 virtual const std::string &getName (void) const = 0;
};
 
// Avec les classes filles qui overloadent la fonction getName pour retourner leur noms

Ou bien si il y a encore une meilleure facon de faire ?!

Merci beaucoup

[aoyou]

Je verrais plutôt un constructeur avec en paramètre le nom et pour les classes filles, un constructeur qui passe le nom au constructeur de la classe mère. Il suffit alors d'écrire une fonction getName () dans la classe mère et c'est tout.
En fait, ça se rapproche de ta première méthode.

[NiamorH]

Un nom, pour un véhicule ?

A la limite la marque et le modèle. Ces deux paramètres ne changeant pas, tu peux les passer dans le constructeur de véhicule comme conseillé, les stocker dans des string dans véhicule comme tu le fait déjà et y accéder en lecture seule.

Maintenant si tu fait pareil pour la couleur et l'immatriculation, ces données sont succeptibles de changer donc il te faudra un SetCouleur( Couleur const & ) pour prévoir le coup.

Le Set devrait à priori être public.

[sinasquax]

Merci a tous pour vos réponses si rapide.

Donc la 1ere solution serait la meilleure ?

Je sais que le code aurait pu etre optimisé en créant un constructeur de la classe de base avec le nom en parametre mais ce que je voulais vraiment savoir, c'est quelle est la meilleure methode point de vue programmation objet.

Parce que je trouve que la 2eme méthode ressemble plus a de la programmation objet avec des méthodes virtuelles que les classes filles implementent car elles sont differentes (elles doivent retourner un nom different) selon chaque classe filles.

Un nom, pour un véhicule ?

A la limite la marque et le modèle. Ces deux paramètres ne changeant pas, tu peux les passer dans le constructeur de véhicule comme conseillé, les stocker dans des string dans véhicule comme tu le fait déjà et y accéder en lecture seule.

Maintenant si tu fait pareil pour la couleur et l'immatriculation, ces données sont succeptibles de changer donc il te faudra un SetCouleur( Couleur const & ) pour prévoir le coup.

Le Set devrait à priori être public.

La classe vehicule est juste un exemple mais pour ce qui est des mutateurs, sachant que le nom est déclaré par les classes filles et ne peut pas etre changé par le code, c'est pour ca que le mutateur est en protected pour que seules les classes filles y accedent.

[NiamorH]

Parce que je trouve que la 2eme méthode ressemble plus a de la programmation objet avec des méthodes virtuelles que les classes filles implementent car elles sont differentes (elles doivent retourner un nom different) selon chaque classe filles.

Ce que tu dis aurait un sens si ce qui se cache derriere GetNom() était complexe à gérer par la classe mère. Mais, dans notre cas, cette méthode ne renverra toujours que le nom, propriété string commune à tous les véhicules. Peu importe que le nom de chaque véhicule soit différent, il s'agit toujours d'un string. Ce serait une perte de temps de redéfinir pour chaque classe fille une méthode GetNom() qui ferrait toujours la même chose : renvoyer m_strNom.

La programmation objet implique aussi de savoir rassembler dans la classe mère les comportements communs.

A la limite tu pourrais imaginer une méthode virtuelle GetDescription() qui concaténerait un ensemble de propriétés sous forme de string. Là il serait intéressant de la redéfinir pour la voiture afin d'ajouter des infos que seule elle peut atteindre : le nombre d'airbag (non dispo pour la moto) etc.

Mais un simple GetNom doit rester dans la classe mère, à priori.

sachant que le nom est déclaré par les classes filles et ne peut pas etre changé par le code, c'est pour ca que le mutateur est en protected pour que seules les classes filles y accedent.

Les classes filles ont-elles réellement besoin de le changer au cours de la vie de l'objet ? Si la réponse est non autant virer le mutateur. Ici je ne voit pas trop le besoin.

[sinasquax]

Merci pour vos réponses, je commence a comprendre en objet

Ce que tu dis aurait un sens si ce qui se cache derriere GetNom() était complexe à gérer par la classe mère. Mais, dans notre cas, cette méthode ne renverra toujours que le nom, propriété string commune à tous les véhicules. Peu importe que le nom de chaque véhicule soit différent, il s'agit toujours d'un string. Ce serait une perte de temps de redéfinir pour chaque classe fille une méthode GetNom() qui ferrait toujours la même chose : renvoyer m_strNom.

La programmation objet implique aussi de savoir rassembler dans la classe mère les comportements communs.

A la limite tu pourrais imaginer une méthode virtuelle GetDescription() qui concaténerait un ensemble de propriétés sous forme de string. Là il serait intéressant de la redéfinir pour la voiture afin d'ajouter des infos que seule elle peut atteindre : le nombre d'airbag (non dispo pour la moto) etc.

Mais un simple GetNom doit rester dans la classe mère, à priori.

Ah ok je comprend maintenant comment savoir si on doit avoir des methodes virtuelles dans les classes filles ou des methodes communes dans la classe mere,

Et joyeux noël a tous

[Alain Defrance]

La polymorphie (ce que tu cherche a exploiter) est souvent utilisé quand une methode présente dans les deux filles auront le meme but, mais que les regle de calcul seront différentes en fonction du type de la classe fille instanciée.
Ainsi on appelle la methode sans se soucier du type de l'instance.
A part si tu a besoin d'effectuer des controls différents en fonction de l'instance (comme certains nom interdits en fonction du type de vehicule), un accesseur pas a être polymorphe.

Par contre attention, une classe est avant tout une structure de donnée, c'est à dire qu'elle va te servir à avoir plusieurs instances différentes ayant des donnée différentes (un petit peut comme des occurences dans une base de donnée).
de ce fait, ils y aura effectivement plusieurs nom différents mais toujours un seul par instance.

Si en revenche tu avait bien vu les choses comme cela, et que tu veux seulement recuperer le type de l'objet précédement instancé, alors tu peut definir une methode (inline ?) qui retourne en dur un code de type. Cette methode n'est ni un get ni un set, et n'as pas lieu d'etre dans la classe mère puisqu'elle sera jamais instancé.

[NiamorH]

Si en revenche tu avait bien vu les choses comme cela, et que tu veux seulement recuperer le type de l'objet précédement instancé, alors tu peut definir une methode (inline ?) qui retourne en dur un code de type. Cette methode n'est ni un get ni un set, et n'as pas lieu d'etre dans la classe mère puisqu'elle sera jamais instancé.

J'ai pas compris.

Une méthode inline qui retourne un code, mais qui ne soit pas un get et qui ne se trouve pas dans la classe mere ? Un exemple ?

[Alain Defrance]

Pour moi les accesseurs doivent être publiques (puisque c'est leurs role d'intermediaire et de controle d'integrité des propriété).

Je mettrait donc un get et un set en public et non en privé ce qui me permettra de controler la donnée de nomporte ou dans son utilisation.
Puisque ici tu defini vehicule comme abstrait je comprend pourquoi tu utilise le protected, mais dans un souci de portabilité (l'objet est dieu a ce niveau la) tu devrais peut-etre penser a une reutilisation directe de cette classe dans une eventuel autre projet.

Les filles utiliserait les accesseurs publiques, et la mère ne pouvant pas etre instancier, un accesseur publique n'ouvre pas plus de porte qu'un accesseur protégé.