Discussion :

[superspike23]

salut a tous,j ai essaye d ecrire un petit programme oriente objet.
Mais je n arrive pas a comprendre la logique de la chose...
Pensez vous que ce code est bien construit??
Merci de me conseillez.

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
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
#include "stdafx.h"
#include <iostream>
#include "math.h"
class polynome // classe qui s occupe du polynome sous la forme y=ax²+bc+c
{
public:
	float lirea();
	float lireb();
	float lirec();
	float lired();
	void defa (float );
	void defb (float );
	void defc (float );
	void defd (float );
	void affichepoly();
	void saisiutilis();
    float calculdelta();
    void affichedelta();
	void solutions();
 
private:
	float sona,sonb,sonc,sond;
 
 
};
 
//methode d acces a a,b,c
float polynome::lirea()
{
	return sona;
}
float polynome::lireb()
{
	return sonb;
}
float polynome::lirec()
{
	return sonc;
}
float polynome::lired()
{
	return sond;
}
void polynome::defa(float a)
{ 
	sona=a;
}
void polynome::defb(float b)
{
	sonb=b;
}
void polynome::defc(float c)
{
	sonc=c;
}
void polynome::defd(float d)
{
	sond=d;
}
 
void polynome::saisiutilis()
{
	float x,y,z;
	std::cout << "\tVeuillez entrer une valeur pour a: ";
	std::cin >> x;
	std::cout << "\tVeuillez entrer une valeur pour b: ";
	std::cin >> y;
	std::cout << "\tVeuillez entrer une valeur pour c: ";
	std::cin >> z;
	defa(x);
	defb(y);
	defc(z);
	affichepoly();
	calculdelta();
 
	affichedelta();
	solutions();
 
 
}
void polynome::affichepoly()
{
std::cout <<"\n\t\tLe polynome  que vous avez saisi est:"<<lirea()<<"x^2+"<<lireb()<<"x+"<<lirec()<<"\n";
}
float polynome::calculdelta()
{
	float a,b,c,d;
	a=lirea();
	b=lireb();
	c=lirec();
	d=(b*b)-(4*a*c);
	defd(d);
 
	return d;
}
void polynome::affichedelta()
{
	std::cout << "\n\t\tDelta= "<<calculdelta();
}
 
void polynome::solutions()
{
	float a,b,c,d;
	a=lirea();
	b=lireb();
	c=lirec();
	d=lired();
	if (d > 0)
 
 
		std::cout <<"\n\tIl y a deux solutions reelles:"<<(-b-sqrt(d))/(2*a)<<" et "<<(-b+sqrt(d))/(2*a);
 
 
 
	if (d==0)
 
		std::cout <<"\n\tIl y a une solution reelle:"<<-b/(2*a);
	if (d<0) 
 
		std::cout <<"\n\tIl n y a pas de solutions reelles";
 
 
}
 
 
int _tmain(int argc, _TCHAR* argv[])
{
	char reponse;
	polynome un;
	un.saisiutilis();
	//un.affichepoly();
	//un.calculdelta();
	//un.affichedelta();
 
 
	std::cin>>reponse;
	return 0;
}

[Inverse]

L'intérêt des fonctions d'accès comme lirea() et defa() permettent de ne pas rendre tout autre code utilisant ta classe polynome au courant de la manière dont tu manipules ces données. A l'intérieur de ta classe, ça n'a aucun sens d'utiliser ces fonctions pour manipuler les données membres de ta classe.

Par la suite, essaye de ne pas inclure les routines de saisies et d'affichage dans tes objets.

Enfin, renseigne toi sur la notation hongroise et les différents style de formattage du code, pour éviter d'avoir des noms de fonction en langue kobold.

Par exemple, void CalculDelta( void ) et les préfixes devant tes variables membres comme float m_fA comme membre de type float de nom A.

Mieux vaut prendre les bonnes habitudes le plus tôt possible

[loufoque]

Pensez vous que ce code est bien construit??

Non.
Ça permet que les polynomes de degré inférieur ou égal à 3.

[superspike23]

en fait au depart j avais cree une seconde classe,mais j arrivais pas les faire communique ensemble.
donc j ai tout mis dans la classe polynome.

[hiko-seijuro]

L'intérêt des fonctions d'accès comme lirea() et defa() permettent de ne pas rendre tout autre code utilisant ta classe polynome au courant de la manière dont tu manipules ces données. A l'intérieur de ta classe, ça n'a aucun sens d'utiliser ces fonctions pour manipuler les données membres de ta classe.

je ne suis pas d'accord, si tu veux changer le type de données mais essayer de garder une cohérence avec le reste de ton code ca peut eviter de réécrire pas mal de chose.

[NewbiZ]

Annotations en vrac:

* Programmes en anglais
* Trouves une convention de codage pour tes fonctions : accesseurs get_x(), mutateurs set_x(), membres suffixe _, fonction première lettre en minuscule, classes première lettre majuscule etc...
* Mets en inline les accesseurs/mutateurs
* Delta est une variable calculée, pas stoquée
* Essayes de rendre la chose aussi indépendante que possible de l'entrée/sortie (demande le stream d'entrée/sortie)
* Les accesseurs pourraient être const
* si tu utilises std, autant le faire à fond: std::endl

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
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
 
#include <cstdlib>
#include <iostream>
#include <sstream>
#include <math.h>
 
class Polynome 
{
public:
  Polynome(float a=0, float b=0, float c=0);
  ~Polynome();
 
  inline float get_a() const;
  inline float get_b() const;
  inline float get_c() const;
 
  inline void set_a( float a );
  inline void set_b( float b );
  inline void set_c( float c );
 
  void set_fromstream( std::istream& is );
 
  std::string to_s() const;
 
  float get_delta() const;
  std::string  get_solutions() const;
private:
  float a_, b_, c_;
};
 
Polynome::~Polynome()
{
}
 
Polynome::Polynome(float a, float b, float c)
{
  set_a(a);
  set_b(b);
  set_c(c);
}
 
inline float Polynome::get_a() const
{
  return a_;
}
 
inline float Polynome::get_b() const
{
  return b_;
}
 
inline float Polynome::get_c() const
{
  return c_;
}
 
inline void Polynome::set_a(float a)
{
  a_ = a;
}
 
inline void Polynome::set_b(float b)
{
  b_ = b;
}
 
inline void Polynome::set_c(float c)
{
  c_ = c;
}
 
void Polynome::set_fromstream( std::istream& is )
{
  std::cout << "Entrez les valeurs:" << std::endl;
 
  std::cout << "a: ";
  is >> a_;
 
  std::cout << "b: ";
  is >> b_;
 
  std::cout << "c: ";
  is >> c_;
}
 
float Polynome::get_delta() const
{
  return (b_*b_)-4*(a_*c_);
}
 
std::string Polynome::to_s() const
{
  std::ostringstream oss;
  oss << "Polynome: " << a_ << "x2+" << b_ << "x+" << c_;
 
  return oss.str();
}
 
std::string Polynome::get_solutions() const
{
  float d = get_delta();
  std::ostringstream oss;
  if (d>0)
  {
    oss << "Il y a deux solutions reelles:" << std::endl;
    oss << "1) " << (-b_-sqrt(d))/(2*a_) << std::endl;
    oss << "2) " << (-b_+sqrt(d))/(2*a_) << std::endl;
  }
  else if (d==0)
  {
    oss << "Il y a une solution reelle:" << std::endl;
    oss << "1) " << -b_/(2*a_) << std::endl;
  }
  else
  {
    oss << "Il n'y a pas de solutions reelles." << std::endl;
  }
  return oss.str();
}
 
int main(int argc, char *argv[])
{
    Polynome p(1,5,3);
    std::cout << p.to_s() << std::endl;
    std::cout << "Delta: " << p.get_delta() << std::endl;
    std::cout << "Solutions: " << p.get_solutions() << std::endl;
 
 
    p.set_fromstream( std::cin );
    std::cout << p.to_s() << std::endl;
    std::cout << "Delta: " << p.get_delta() << std::endl;
    std::cout << "Solutions: " << p.get_solutions() << std::endl;
 
    system("PAUSE");
    return EXIT_SUCCESS;
}

[NewbiZ]

L'intérêt des fonctions d'accès comme lirea() et defa() permettent de ne pas rendre tout autre code utilisant ta classe polynome au courant de la manière dont tu manipules ces données. A l'intérieur de ta classe, ça n'a aucun sens d'utiliser ces fonctions pour manipuler les données membres de ta classe.

Trivialement oui, mais ca ne sert pas qu'à ca :
* si tu veux stoquer tes données sous un autre format
* si tu veux restreindre tes données (dans l'exemple, limiter aux a>0 par exemple)
Bref l'encapsulation ne peut être à mon sens qu'une bonne chose.

[Luc Hermitte]

En vrac.

Programmer OO ne rime pas avec mettre des accesseurs et mutateurs à tous les coins de rues (/de classe). Ici, je préfère avoir des fonctions qui modifient un polynôme dans son ensemble (tous les opérateurs de l'algèbre qui va bien), plus un constructeur à partir d'un tableau de coefficients plutôt que des mutateurs qui violent l'encapsulation en exposant des détails.

La notation hongroise, ce n'est pas préfixer par le type informatique (type ; syntaxique ?) de la donnée, mais par le "type catégorie" (kind ; sémantique ?).
Une bonne lecture : http://www.joelonsoftware.com/articles/Wrong.html.

AMHA, Le get_solution() n'a pas sa place dans la portée de polynôme. Cette fonction est liée à une équation ; équation ici linéaire définie par un polynôme.

Et effectivement, des détails C++ (!= OO) peuvent être améliorés : il manque plein de "const", <iostream> n'a pas sa place dans un .h, à termes un vecteur sera mieux (voire mieux un valarray), ...

[Inverse]

je ne suis pas d'accord, si tu veux changer le type de données mais essayer de garder une cohérence avec le reste de ton code ca peut eviter de réécrire pas mal de chose.

"Find & Replace".

NewbiZ:

C'est stupide de chercher à *encapsuler* à l'intérieur de la classe même.

[NewbiZ]

Programmer OO ne rime pas avec mettre des accesseurs et mutateurs à tous les coins de rues (/de classe).

Il n'est pas question de réduire l'OO à ça, mais le principe d'encapsulation est l'un des préceptes de base de l'OO, l'interface publique des objets a donc tout a fait sa place dans le débat.

Ici, je préfère avoir des fonctions qui modifient un polynôme dans son ensemble (tous les opérateurs de l'algèbre qui va bien), plus un constructeur à partir d'un tableau de coefficients plutôt que des mutateurs qui violent l'encapsulation en exposant des détails.

AMHA, Le get_solution() n'a pas sa place dans la portée de polynôme. Cette fonction est liée à une équation ; équation ici linéaire définie par un polynôme.

Pourquoi confondre les niveaux d'abstraction ? le fait que l'interface publique soit relativement similaire à la structure interne de l'objet n'est en rien un problème, et ne constitue pas, en soit, une violation de l'encapsulation.

Selon ton utilisation, tu peux considérer un polynome comme un objet mathématique (conception par entité), ou comme une variable à calculer (conception par valeur) ; pourquoi opposer ces deux modélisations ?

C'est stupide de chercher à *encapsuler* à l'intérieur de la classe même.

C'est prendre le problème à l'envers.
Adopter une politique d' "encapsulation totale" dès le début te permet justement de passer à une agrégation plus tard, de manière transparente.

[hiko-seijuro]

"Find & Replace".

bah oui mais bon c'est juste une façon de faire. Moi je preferre passer par des accesseurs, je trouve ca plus propre

[superspike23]

J'avoue que je n ai pas tout suivi a la conversation.
Comment modeliser un polynome dans son ensemble?
ca me semble beaucoup plus pointu d un point de vue mathematique je m entend.

[Luc Hermitte]

Il n'est pas question de réduire l'OO à ça, mais le principe d'encapsulation est l'un des préceptes de base de l'OO, l'interface publique des objets a donc tout a fait sa place dans le débat.

Je réagissais au fait que je trouve que cette classe me laisse craindre que l'OP ait été abusé à croire que toute donnée privée doit avoir son couple accesseur/mutateur. Cette règle est n'importe quoi ; je réagissais "préventivement".

Exposer des détails d'implémentation romp les fondements de l'encapsulation : servir à définir des abstractions. Dès que l'on expose un détail d'implémentation ben ... on n'encapsule plus grand chose.

Pourquoi confondre les niveaux d'abstraction ?

?? (au cas où tu répondais à la partie relative à get_solution() ; j'ai un doute par rapport à l'organisation des citations)
Un polynome est un objet mathématique qui dispose de sa propre algèbre -- corps ou anneau, j'avoue que tout cela remonte à trop longtemps pour que je m'en souvienne.
Un polynome est mi-valeur, mi-fonction. Je les range dans la catégorie de immuables. On touche à un morceau de l'état, et bien ce n'est plus le même polynôme, c'en est un autre.

En revanche, une équation se résoud. Et ce n'est pas parce que les équations linéraires peuvent avoir un état implémenté par un polynôme que la résolution de l'équation relève de la responsabilité du polynôme. Autant rajouter une opération resolve à toutes les classes vecteurs que l'on pourrait être amenés à définir. C'est exactement pareil : un vecteur n'est pas une équation, un polynôme n'est pas une équation.

le fait que l'interface publique soit relativement similaire à la structure interne de l'objet n'est en rien un problème, et ne constitue pas, en soit, une violation de l'encapsulation.

Quand il s'agit d'un détail sans intérêt, si complètement. Le tout est de bien définir l'interface publique.
Bon, j'avoue et admets que pour un polynôme il peut être acceptable d'avoir des mutateurs de si fine granularité. Assez étrangement, disposer de l'opérateur [] m'aurait moins perturbé.

Selon ton utilisation, tu peux considérer un polynome comme un objet mathématique (conception par entité), ou comme une variable à calculer (conception par valeur) ; pourquoi opposer ces deux modélisations ?

La sémantique des objets mathématiques est généralement un rafinement de la sémantique de valeur. Sans ça, point d'opérateurs mathématiques surchargés en C++.

[Médinoc]

<iostream> n'a pas sa place dans un .h

Là, deux écoles s'affrontent: Pour certains, un fichier d'en-tête doit "se suffire à lui-même" et inclure tout les fichiers d'en-tête dont il a besoin (même si j'inclus rarement windows.h, car on peut décider d'en exclure des parties).

Par contre, il est reconnu qu'un using namespace n'a pas sa place dans un .h (tant mieux, puisqu'il n'y en avait pas ici).


PS:
superspike23: Inutile d'utiliser _tmain() si tu n'utilises pas les TCHARs, ce qui est assez difficile en C++ (il n'y a pas de type basic_string< TCHAR > déclaré par défaut). Sans TCHAR, main() suffit.
superspike23 & NewbiZ: Je pense que quand on n'utilise pas les arguments de main(), il est inutile de les mettre. De plus, gcc bien réglé (ou Visual en Warning niv.4) donnera un warning "unused parameter"...

[NewbiZ]

Je pense que quand on n'utilise pas les arguments de main(), il est inutile de les mettre. De plus, gcc bien réglé (ou Visual en Warning niv.4) donnera un warning "unused parameter"...

Ca fait un C-like de ne pas déclarer les paramètres non ?
Pour les arguments non déclarés, seul un compilateur avec des flags paranoiaques y fera référence, et encore heureux, je me rapelle qu'on devait faire un (void*) arg; pour le faire compiler sous GCC, c'est censé être plus beau? (mais dans les dernières versions il détecte ce genre de "bidouilles")
Toujours est-il que les messages du compilateur ne sont pas une référence de coding style a mes yeux :>

[Médinoc]

Ca fait un C-like de ne pas déclarer les paramètres non ?

???
Je ne comprends pas ce que tu veux dire, là... Les deux prototypes de main() sont les mêmes en C et en C++...

Pour les arguments non déclarés, seul un compilateur avec des flags paranoiaques y fera référence, et encore heureux, je me rapelle qu'on devait faire un (void*) arg; pour le faire compiler sous GCC, c'est censé être plus beau? (mais dans les dernières versions il détecte ce genre de "bidouilles")
Toujours est-il que les messages du compilateur ne sont pas une référence de coding style a mes yeux :>

(void)arg, pas (void*)arg...

[Luc Hermitte]

[de <iostream> qui n'a pas sa place dans un .h...]
Là, deux écoles s'affrontent: Pour certains, un fichier d'en-tête doit "se suffire à lui-même" et inclure tout les fichiers d'en-tête dont il a besoin (même si j'inclus rarement windows.h, car on peut décider d'en exclure des parties).

Ca, c'est autre chose. Je faisais référence au fait que:
<iostream> => std::cout, std::cin, std::cerr, std::clog
<iosfwd> => déclaration anticipée de std::istream, std::ostream
<istream> => définition de std::istream
<ostream> => définition de std::ostream

std::cout n'ayant pas sa place dans un .h, <iostream> non plus.

[Médinoc]

En effet, je n'avais pas vu qu'aucune fonction inline n'utilisait cout.