Discussion :

[St-42-FCM-57]

Bonjour,

J'ai trouvé un petit exercice, mais je ne sais pas comment faire sur un point.

J'ai une classe Meuble qui hérite de ElementCuisine. Dans l'énoncé il est écrit qu'on peut ajouter une option à un meuble (une poignée ou un matériau par exemple). Dans le cas d'une poignée, on ajoutera son prix au prix du meuble. Dans le cas d'un matériau, on appliquera une majoration au prix du meuble.
Donc j'ai fait un classe Option, et une classe Poignee qui hérite de Option. Dans ma classe Meuble, j'ai créer un vector d'Option* et une méthode d'ajout qui va avec.

Avant d'aller plus loin, je me pose la question suivante : comment, dans ma Classe Meuble, lorsque je vais parcourir mon vector d'Option* pour calculer le prix du meuble, je vais réussir à faire la différence entre une Poignee et un Materiau ?

Merci d'avance pour les pistes apportées !

[oodini]

Tu n'as pas à faire la différence. Tu dois simplement récupérer leur prix.

[St-42-FCM-57]

Oui mais on calcule pas de la même facon si c’est l’option est une poignée ou matériau. Par exemple si mon meuble coûte de base 20€. J’ajoute une poignée à 10€, donc le prix du meuble devient 20+10. Si l’option est un materiau, elle va par exemple augmenter le prix du meuble de 10%, donc celui-ci deviendra 20+20*10%.

On remarque bien que le calcul n’est pas le même selon le type de l’option, non ?

[ternel]

Tu peux avoir une seconde fonction qui indique si le prix est une majoration ou une pièce supplémentaire.

Fais-le à la main, sans code
Ta liste contient:

1. une lampe à 15€
2. un frigo à 100€
3. un meuble à 30€ en bois (+20%)
4. un meuble à 20€ avec poignée (+10€)

la fonction prix() du meuble doit retourner le prix final (le prix de base modifié par l'option).
L'option doit pouvoir calculer un prix modifié quand on lui donne un prix de base. prix_final(prix)J'imagine que auto meuble::prix() const { return has_option() ? option().prix(prix_base) : prix_base; } devrait faire l'affaire.

[Bousk]

C'est exactement ce pour quoi est fait le mot-clé virtual et l'abstraction (et un autre terme qui m'échappe).
Tu n'as pas à savoir que ton objet est un matériau ou une poignée, tu as besoin de savoir combien coûte l'option.
Si tu veux garder une distinction entre eux, l'héritage n'a rien à faire et une collection homogène encore moins.

[St-42-FCM-57]

Merci pour vos réponses.
J'avais réussi avec une fonction dans option :

Code :

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

 virtual const double prix(double prix) const = 0;

que je dérivais par exemple dans Materiau par :

Code :

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

1
2
 
const double prix(double prix) const { prix*_majoration; }

Ca marchait bien, enfin ça donnait le resultat espéré.
Seulement je me suis rendu compte après, que si je mettais un meuble comme paramètre de la fonction prix dans Option, je pouvais accéder au prix du meuble justement.
Ainsi ma fonction devient comme ça :

Code :

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

1
2
 
virtual const double prix(const Meuble m) const = 0;

Et dans Materiau :

Code :

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

1
2
 
const double prix(const Meuble m) const { return m.getPrix()*_majoration; }

Dans meuble pour calculer le prix final je fais ceci :

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
 
const double Meuble::prixFinal() const
{
	double somme = 0;// 
	if (_lesOptions.size() >= 1)
	{
		for (int i(0); i < _lesOptions.size(); i++)
		{
			somme += _lesOptions[i]->prix(this);
		}
	}
	else
	{
		somme = _prix;
	}
	return somme;
}

Seulement maintenant j'ai un nombre incalculable d'erreurs, je ne vois pas ce que je fais de mal pourtant ?

[ternel]

Pourquoi donner le meuble en argument, si tu ne veux que le prix?

Si tu as plusieurs options, ma solution est mauvaise.
Tu as des options s'ajoutant au prix, et d'autres qui le multiplient.
Il te faut deux listes, sous peine d'avoir des erreurs.
Ainsi, "un meuble, avec une poignée, fait en bois" couterait (10 + 10) * 1,2
ce qui est différent d'"un meuble, fait en bois, avec une poignée" 10 * 1,2 + 10

[St-42-FCM-57]

Je veux mettre un meuble en paramètres car une autre option dans le sujet est "Pieds", et le prix de cette option dépend de la taille du meuble. Ainsi, si je le mets en paramètres, je peux accéder à sa taille, à son prix ...

Du coup c'est 2 listes de quoi qu'il faut que je fasse ?

[ternel]

Il faut séparer les surcoût multiplicatifs (exprimé en ratio) des prix additifs (exprimés en unité monétaire).

Tes matériaux ne sont pas des options comme les autres, car elle multiplie les prix.
D'ailleurs, ils pourraient aussi s'appliquer aux autres options (une poignée en cuivre ou en or?).

Un meuble ne peut avoir qu'un seul matériau comme option, et ils doivent logiquement toujours en avoir un (le matérieau de base, facteur 1).

[St-42-FCM-57]

Si je fais 3 vector pour mes 3 options, je ne peux plus avoir d'héritage du coup ? Parce que vector<Poignee> il ne me l'acceptera pas par exemple ?

[bacelar]

L'approche de @St-42-FCM-57 n'est pas forcement mauvaise.
Elle implique un couplage fort entre les classes Meuble/Option/Materiau, ce qui n'est pas très bon pour la réutilisabilité, mais Rome ne c'est pas faite en un jour.
Attention à l'ordre des calculs de prix, car le mélange de multiplication et d'adition brise la commutativité des calculs.

Montres-nous ton code et les messages d'erreurs.

[St-42-FCM-57]

Maintenant j'ai plus de 100 erreurs, ça va être difficile de les lister...
Je vous montre les parties de code qui entre en compte dans mon soucis.

Option.h

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
 
 
class Option
{
private:
	string _nomOption;
 
public:
 
	Option(string _nom);
	~Option();
	friend ostream & operator << (ostream &, const Option &);
 
	virtual const double prix(const Meuble m) const = 0;
	virtual const double getPrix() const = 0;
 
 
	inline virtual void affiche(ostream &s) const;
};
 
void Option::affiche(ostream &s) const {
	s << "Option : [ nomOption = " << _nomOption << "]" << endl;
}
 
inline ostream & operator << (ostream &s, const Option &op)
{
	op.affiche(s);
	return s;
}

Materiau.h

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
 
 
class Materiau:public Option
{
private:
	double _majoration;
public:
	Materiau(string _nom, double maj);
	~Materiau();
	const double getPrix() const { return _majoration; }
	const double prix(const Meuble m) const 
	{ 
		return m.getPrix()*(_majoration);
	}
 
	inline void affiche(ostream &s) const;
};
 
void Materiau::affiche(ostream &s) const
{
	s << "Option Materiau: [";
	Option::affiche(s);
	s << " Prix = " << this->getPrix() << " Euros ]" << endl;
}

Méthode dans Meuble.cpp

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
 
 
const double Meuble::prixFinal() const
{
	double somme = 0;
	if (_lesOptions.size() >= 1)
	{
		for (int i(0); i < _lesOptions.size(); i++)
		{
			//somme += _lesOptions[i]->getPrix();
			somme += _lesOptions[i]->prix(this);
		}
	}
	else
	{
		somme = _prix;
	}
	return somme;
}

EDIT :

J'ai remis comme toute à l'heure avec des double, mais rien ne fonctionne, alors que toute à l'heure tout marchait avec des double.
Le première erreur que j'ai c'est : "Option : classe de base non définie" dans materiau.h

[Bktero]

J'arrive un peu après la bataille mais pourquoi ne pas séparer tes options en deux catégories:
1- des finitions : elles modifient le prix de base de ton meuble avec un % (20% pour de l'érable, 50% pour un plaquage en or)
2- des compléments: elle rajoute un prix fixe au prix de base augmenté des % des finitions (10€ pour une poignée simple, 500€ pour une poignée en diamant).
Tu aurais deux vecteurs d'options.

Ah en fait ternel a déjà fait une proposition équivalente...

[bacelar]

Maintenant j'ai plus de 100 erreurs, ça va être difficile de les lister...

On s'en fout du nombre.
Dés que le compilateur tombe sur une erreur, généralement, il part en sucette car il ne comprend plus rien après.
Donc seules les premières erreurs sont pertinentes. (plusieurs car une erreur peu engendrer plusieurs messages d'erreur)
Donc les 5-10 premiers messages d'erreurs seront largement suffisants.

Votre code montre que vous n'avez pas une vue claire de comment devrait être calculer un prix.
Il faut commencer par avoir une vue claire de comment devrait être calculer un prix avant de l'implémenter.
Comme c'est des règles business, on peut pas le faire à votre place.

la classe "Option" est sensé avoir des classes dérivées, son destructeur doit être virtuel.
Une méthode "prix" et une méthode "getPrix", c'est clairement un truc à emmerde.
Il faut des noms EXPLICITES sur leur fonction.
Le fait de ne pas avoir des noms explicites montre qu'on ne sait pas ce que cela doit faire, résultat, l'implémentation fait un peu nimportnawak.

Un Matériau n'a pas de prix => Une option n'a pas de prix. Et pour calculer un prix, il faudrait le prix de base du meuble (c'est dans l'objet meuble, OK) mais aussi le prix "actuel" quand les modificateurs se basent pas sur le prix de base mais sur le prix après modifications des options précédentes.
Option Rouge : +20%
Option Brillant : +10%
Mais l'option Rouge + Brillant, c'est quoi ?
- Prix de base * (20%+20%) ?
- Prix de base * (20%) *(20%) ?

Un Matériau n'a pas de prix, mais un facteur modificateur. On dégage de getPrix tout pourri.

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
 
classe IMeuble
{
public :
	double prixDeBase;
}
 
classe Meuble : public IMeuble
{
...
}
 
...
{
...
	virtual const double calculPrixFinal(double prixCourant, const IMeuble& meuble) const = 0;
...
}
...
Materiau::calculPrixFinal(double prixCourant, const IMeuble& meuble) const
{
	return prixCourant + (meuble.prixDeBase * modificateur);
}
...
Materiau2::calculPrixFinal(double prixCourant, const IMeuble& meuble) const
{
	return (prixCourant * modificateur);
}
...
 
Poignee::calculPrixFinal(double prixCourant, const IMeuble& meuble) const
{
	return prixCourant + _prixUnitaire;
}

Code :

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

1
2
3
4
5
6
7
8
9
const double Meuble::prixFinal() const
{
	double somme = _prix;
	for (int i(0); i < _lesOptions.size(); i++)
	{
		somme = _lesOptions[i]->calculPrixFinal(somme,this);
	}
	return somme;
}

Pour le message d'erreur, faudrait penser à pas oublier les #include qui vont bien.

[Pyramidev]

Bonjour,

Quand on crée une classe avec des fonctions virtuelles, en général, l'idée qu'on a derrière, c'est qu'il existe une portion du code qui connaît la classe de base sans connaître les classes dérivées. Alors, le jour où on crée une nouvelle classe dérivée, on n'a pas besoin de changer cette portion du code.

Pour l'affichage des options d'un meuble, un héritage peut être intéressant. Par exemple, la vue afficherait les options sous la forme d'un tableau avec une ligne par option. On pourrait avoir une colonne qui contient le nom de l'option, une autre qui contient une image et une autre qui contient une description. La vue appellerait des fonctions virtuelles d'une classe Option, sans en connaître les classes dérivées.

Par contre, pour le calcul du prix, s'appuyer sur un arbre d'héritage me semble être une mauvaise idée. Par exemple, admettons qu'on ait une nouvelle option "couche de peinture" dont le prix peut bénéficier d'une réduction si l'utilisateur a aussi choisi une option "matériau". Dans un tel cas, si on a essayé de rendre générique le calcul du prix à coup d'héritage, tous les efforts tombent par terre. Du coup, à mon avis, il vaudrait mieux que le code qui calcule le prix soit directement capable de distinguer quelles options sont des poignées, lesquelles sont des matériaux, etc. Le couplage est fort, mais tant pis.

Du coup, je pense que j'aurais instancié un std::optional ou un conteneur pour chaque type d'option, par exemple un std::optional<OptionPoignee>, un std::optional<OptionMateriau>, etc. Le code qui calcule le prix parcourrait chacun de ces objets.

En ce qui concerne l'affichage, par contre, je me serais appuyé sur l'héritage. Par exemple, j'aurais créé aussi un std::vector<std::reference_wrapper<const Option>>. Le code qui gère l'affichage parcourrait ce vecteur, sans connaître le type réel des options.

[JolyLoic]

J'ai l'impression que l’énoncé de l'exercice tend à pousser vers le design pattern décorateur... Chaque option vient décorer le meuble de base, et en modifier le prix.