Bonjour,
J'aimerais bien créer quelques classes qui dérivent de certains conteneurs
de la STL. Je sais que ces derniers ne sont pas conçus pour être dérivés,
mais sachant que le but est simplement de :
- créer un vrai nouveau type au lieu d'un typedef
- ne pas ajouter de donnée membre mais uniquement dfes fonctions
est-ce une pratique acceptable ?
Exemple:
class SortedData : public std::set<int>
{
public:
SortedData( const std::vector<int> & Vect )
{
this->insert( Vect.begin(), Vect.end() );
}
// calcule la moyenne
double Average() const
{
int total = 0;
total = std::accumulate( this->begin(), this->end(), total );
return total * 1.0 / this->size();
}
};
J'ai une classe "Charge" qui décrit des charges électrostatique J'ai une classe "Charges" qui est une "collection" de toutes les charges.
Depuis mon programme principal il faut je j'affiche chaque charge... Donc il faut parcourir "Charges" depuis l'extérieur...
typedef std::list<Charge> Charges;
ça suffit pas ?
non ça ne suffit pas car il me faut aussi des méthodes... Quelle est la charge la plus proche de (x,y) ? Est-ce que (x,y) est proche d'une charge ? Dessiner toutes les charges...
etc...
Es tu sûr de n'avoir jamais à traiter ultérieurement des charges non ponctuelles ? Parce que les questions que tu poses là sont bien en amont de la notion de charge, c'est de la géométrie. Moi je traiterais ça dans une classe point, et ensuite, parmi les propriétés d'une charge concrète, il y aurait sa position d'une part (membre point), et sa charge électrique (membre donnée ou objet, selon ce que tu en attends). Bref, je ne trouve pas que ce soit une bonne idée de mélanger la géométrie avec les propriétés électriques proprement dites - d'autant que les premières seront, je pense, cernées bien plus vite que les secondes. Une seconde raison est que le jour où tu voudras traiter du magnétisme, ou d'ailleurs n'importe quoi d'autre, tu auras déjà ta ou tes classe(s) de géométrie. Enfin, bon, moi ce que je dis, hein... Mais ne pas penser aux évolutions en conception objet, c'est n'en garder que les contraintes tout en perdant l'avantage majeur.
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
<noone@nowhere.com> a écrit dans le message news:
41f0904e$0$31822$8fcfb975@news.wanadoo.fr...
J'ai une classe "Charge" qui décrit des charges électrostatique
J'ai une classe "Charges" qui est une "collection" de toutes les
charges.
Depuis mon programme principal il faut je j'affiche chaque charge...
Donc il faut parcourir "Charges" depuis l'extérieur...
typedef std::list<Charge> Charges;
ça suffit pas ?
non ça ne suffit pas car il me faut aussi des méthodes...
Quelle est la charge la plus proche de (x,y) ?
Est-ce que (x,y) est proche d'une charge ?
Dessiner toutes les charges...
etc...
Es tu sûr de n'avoir jamais à traiter ultérieurement des charges
non ponctuelles ? Parce que les questions que tu poses là sont
bien en amont de la notion de charge, c'est de la géométrie.
Moi je traiterais ça dans une classe point, et ensuite, parmi les
propriétés d'une charge concrète, il y aurait sa position d'une
part (membre point), et sa charge électrique (membre donnée
ou objet, selon ce que tu en attends). Bref, je ne trouve pas que
ce soit une bonne idée de mélanger la géométrie avec les
propriétés électriques proprement dites - d'autant que les premières
seront, je pense, cernées bien plus vite que les secondes.
Une seconde raison est que le jour où tu voudras traiter du
magnétisme, ou d'ailleurs n'importe quoi d'autre, tu auras déjà
ta ou tes classe(s) de géométrie.
Enfin, bon, moi ce que je dis, hein... Mais ne pas penser aux
évolutions en conception objet, c'est n'en garder que les
contraintes tout en perdant l'avantage majeur.
--
Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - anaigeon@free.fr - Strasbourg, France
J'ai une classe "Charge" qui décrit des charges électrostatique J'ai une classe "Charges" qui est une "collection" de toutes les charges.
Depuis mon programme principal il faut je j'affiche chaque charge... Donc il faut parcourir "Charges" depuis l'extérieur...
typedef std::list<Charge> Charges;
ça suffit pas ?
non ça ne suffit pas car il me faut aussi des méthodes... Quelle est la charge la plus proche de (x,y) ? Est-ce que (x,y) est proche d'une charge ? Dessiner toutes les charges...
etc...
Es tu sûr de n'avoir jamais à traiter ultérieurement des charges non ponctuelles ? Parce que les questions que tu poses là sont bien en amont de la notion de charge, c'est de la géométrie. Moi je traiterais ça dans une classe point, et ensuite, parmi les propriétés d'une charge concrète, il y aurait sa position d'une part (membre point), et sa charge électrique (membre donnée ou objet, selon ce que tu en attends). Bref, je ne trouve pas que ce soit une bonne idée de mélanger la géométrie avec les propriétés électriques proprement dites - d'autant que les premières seront, je pense, cernées bien plus vite que les secondes. Une seconde raison est que le jour où tu voudras traiter du magnétisme, ou d'ailleurs n'importe quoi d'autre, tu auras déjà ta ou tes classe(s) de géométrie. Enfin, bon, moi ce que je dis, hein... Mais ne pas penser aux évolutions en conception objet, c'est n'en garder que les contraintes tout en perdant l'avantage majeur.
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
noone
Es tu sûr de n'avoir jamais à traiter ultérieurement des charges non ponctuelles ?
j'ai envisagé ça mais c'est un premier développement en C++ donc du calme ;-)
Charge pontuelle pour l'instant puis densité surfacique de charge puis volumique
vue en 3d avec OpenGL etc...
mais il y a du boulot...
donc pour l'instant c'est de la 2D avec charges ponctuelles ;-)
Parce que les questions que tu poses là sont
bien en amont de la notion de charge, c'est de la géométrie. Moi je traiterais ça dans une classe point, et ensuite, parmi les propriétés d'une charge concrète, il y aurait sa position d'une part (membre point),
J'ai défini pour ça la classe Position
et sa charge électrique (membre donnée
ou objet, selon ce que tu en attends). Bref, je ne trouve pas que ce soit une bonne idée de mélanger la géométrie avec les propriétés électriques proprement dites - d'autant que les premières seront, je pense, cernées bien plus vite que les secondes. Une seconde raison est que le jour où tu voudras traiter du magnétisme, ou d'ailleurs n'importe quoi d'autre, tu auras déjà ta ou tes classe(s) de géométrie.
j'ai déjà commencé la partie magnétostatique...
Enfin, bon, moi ce que je dis, hein... Mais ne pas penser aux évolutions en conception objet, c'est n'en garder que les contraintes tout en perdant l'avantage majeur.
je veux déjà que ça marche à peu prêt quitte à refondre ensuite...
Si vous êtes interessé par le projet je suis preneur...
http://s.cls.free.fr/index.php?page=contact
Et j'ai beaucoup à apprendre... (et un peu de temps... mais pas trop quand même !)
Es tu sûr de n'avoir jamais à traiter ultérieurement des charges
non ponctuelles ?
j'ai envisagé ça mais c'est un premier développement en C++ donc du
calme ;-)
Charge pontuelle pour l'instant
puis densité surfacique de charge puis volumique
vue en 3d avec OpenGL etc...
mais il y a du boulot...
donc pour l'instant c'est de la 2D avec charges ponctuelles ;-)
Parce que les questions que tu poses là sont
bien en amont de la notion de charge, c'est de la géométrie.
Moi je traiterais ça dans une classe point, et ensuite, parmi les
propriétés d'une charge concrète, il y aurait sa position d'une
part (membre point),
J'ai défini pour ça la classe Position
et sa charge électrique (membre donnée
ou objet, selon ce que tu en attends). Bref, je ne trouve pas que
ce soit une bonne idée de mélanger la géométrie avec les
propriétés électriques proprement dites - d'autant que les premières
seront, je pense, cernées bien plus vite que les secondes.
Une seconde raison est que le jour où tu voudras traiter du
magnétisme, ou d'ailleurs n'importe quoi d'autre, tu auras déjà
ta ou tes classe(s) de géométrie.
j'ai déjà commencé la partie magnétostatique...
Enfin, bon, moi ce que je dis, hein... Mais ne pas penser aux
évolutions en conception objet, c'est n'en garder que les
contraintes tout en perdant l'avantage majeur.
je veux déjà que ça marche à peu prêt quitte à refondre ensuite...
Si vous êtes interessé par le projet je suis preneur...
http://s.cls.free.fr/index.php?page=contact
Et j'ai beaucoup à apprendre... (et un peu de temps... mais pas trop
quand même !)
Es tu sûr de n'avoir jamais à traiter ultérieurement des charges non ponctuelles ?
j'ai envisagé ça mais c'est un premier développement en C++ donc du calme ;-)
Charge pontuelle pour l'instant puis densité surfacique de charge puis volumique
vue en 3d avec OpenGL etc...
mais il y a du boulot...
donc pour l'instant c'est de la 2D avec charges ponctuelles ;-)
Parce que les questions que tu poses là sont
bien en amont de la notion de charge, c'est de la géométrie. Moi je traiterais ça dans une classe point, et ensuite, parmi les propriétés d'une charge concrète, il y aurait sa position d'une part (membre point),
J'ai défini pour ça la classe Position
et sa charge électrique (membre donnée
ou objet, selon ce que tu en attends). Bref, je ne trouve pas que ce soit une bonne idée de mélanger la géométrie avec les propriétés électriques proprement dites - d'autant que les premières seront, je pense, cernées bien plus vite que les secondes. Une seconde raison est que le jour où tu voudras traiter du magnétisme, ou d'ailleurs n'importe quoi d'autre, tu auras déjà ta ou tes classe(s) de géométrie.
j'ai déjà commencé la partie magnétostatique...
Enfin, bon, moi ce que je dis, hein... Mais ne pas penser aux évolutions en conception objet, c'est n'en garder que les contraintes tout en perdant l'avantage majeur.
je veux déjà que ça marche à peu prêt quitte à refondre ensuite...
Si vous êtes interessé par le projet je suis preneur...
http://s.cls.free.fr/index.php?page=contact
Et j'ai beaucoup à apprendre... (et un peu de temps... mais pas trop quand même !)
James Kanze
wrote:
Ces fonctions-là doivent-elles en être membres ? J'aurais vu plutôt des fonctions libres ; éventuellement même des fonctions template (à deux itérateurs).
pourquoi 2 itérateurs ?
Parce que c'est l'idiome standard en C++.
(Pour la première, je me démande
même s'il ne faut pas une fonction find_best, puis un object fonctionnel pour comparer la distance -- bind2nd de Distance, peut-être.
Qu'est-ce qu'un objet fonctionnel ?
Un objet dont le type a une fonction member operator(). C-à-d un objet qu'on peut utiliser comme une fonction.
bind2nd ?
Une fonction standard de C++. Il prend un objet fonctionnel avec un operator() à deux paramètres (disons Distance), et une valeur pour le deuxième paramètre, et il crée un objet fonctionnel avec un operator() à un seul paramètre.
Pour la deuxième, il y a déjà find_if,
et pour la
troisième, for_each.
oui
Chaque fois avec le Predicate ou l'objet
fonctionnel qui convient.)
j'avoue ne pas être très à l'aise avec ce concept de "Predicate"
Pour dire simplement, c'est un objet fonctionnel dont l'operator() renvoie bool. Ou quelque chose qui se convertit en bool. (Le langage dans la norme est sans doute plus pointieux, mais je crois que ceci est suffisant pour l'utilisation quotidienne.)
Dans la norme, c'est un « concept », c-à-d quelque chose qui apparaît dans plusieurs contextes, et dont on définit une fois pour tout les caractèristiques, en leur donnant un nom. En somme, c'est le b a ba de la bibliothèque standard : les itérateurs sont des concepts, par exemple. (Et on remarque, dans le cas des itérateurs, qu'il y a de l'héritage dans les concepts.)
-- James Kanze home: www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
noone@nowhere.com wrote:
Ces fonctions-là doivent-elles en être membres ? J'aurais vu
plutôt des fonctions libres ; éventuellement même des
fonctions template (à deux itérateurs).
pourquoi 2 itérateurs ?
Parce que c'est l'idiome standard en C++.
(Pour la première, je me démande
même s'il ne faut pas une fonction find_best, puis un object
fonctionnel pour comparer la distance -- bind2nd de Distance,
peut-être.
Qu'est-ce qu'un objet fonctionnel ?
Un objet dont le type a une fonction member operator(). C-à-d un
objet qu'on peut utiliser comme une fonction.
bind2nd ?
Une fonction standard de C++. Il prend un objet fonctionnel avec
un operator() à deux paramètres (disons Distance), et une valeur
pour le deuxième paramètre, et il crée un objet fonctionnel avec
un operator() à un seul paramètre.
Pour la deuxième, il y a déjà find_if,
et pour la
troisième, for_each.
oui
Chaque fois avec le Predicate ou l'objet
fonctionnel qui convient.)
j'avoue ne pas être très à l'aise avec ce concept de "Predicate"
Pour dire simplement, c'est un objet fonctionnel dont
l'operator() renvoie bool. Ou quelque chose qui se convertit en
bool. (Le langage dans la norme est sans doute plus pointieux,
mais je crois que ceci est suffisant pour l'utilisation
quotidienne.)
Dans la norme, c'est un « concept », c-à-d quelque chose qui
apparaît dans plusieurs contextes, et dont on définit une fois
pour tout les caractèristiques, en leur donnant un nom. En
somme, c'est le b a ba de la bibliothèque standard : les
itérateurs sont des concepts, par exemple. (Et on remarque, dans
le cas des itérateurs, qu'il y a de l'héritage dans les
concepts.)
--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Ces fonctions-là doivent-elles en être membres ? J'aurais vu plutôt des fonctions libres ; éventuellement même des fonctions template (à deux itérateurs).
pourquoi 2 itérateurs ?
Parce que c'est l'idiome standard en C++.
(Pour la première, je me démande
même s'il ne faut pas une fonction find_best, puis un object fonctionnel pour comparer la distance -- bind2nd de Distance, peut-être.
Qu'est-ce qu'un objet fonctionnel ?
Un objet dont le type a une fonction member operator(). C-à-d un objet qu'on peut utiliser comme une fonction.
bind2nd ?
Une fonction standard de C++. Il prend un objet fonctionnel avec un operator() à deux paramètres (disons Distance), et une valeur pour le deuxième paramètre, et il crée un objet fonctionnel avec un operator() à un seul paramètre.
Pour la deuxième, il y a déjà find_if,
et pour la
troisième, for_each.
oui
Chaque fois avec le Predicate ou l'objet
fonctionnel qui convient.)
j'avoue ne pas être très à l'aise avec ce concept de "Predicate"
Pour dire simplement, c'est un objet fonctionnel dont l'operator() renvoie bool. Ou quelque chose qui se convertit en bool. (Le langage dans la norme est sans doute plus pointieux, mais je crois que ceci est suffisant pour l'utilisation quotidienne.)
Dans la norme, c'est un « concept », c-à-d quelque chose qui apparaît dans plusieurs contextes, et dont on définit une fois pour tout les caractèristiques, en leur donnant un nom. En somme, c'est le b a ba de la bibliothèque standard : les itérateurs sont des concepts, par exemple. (Et on remarque, dans le cas des itérateurs, qu'il y a de l'héritage dans les concepts.)
-- James Kanze home: www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Marc Boyer
wrote:
Il me semble que rendre le fait que ta representation actuelle est une liste *n'est pas* un bon choix. Par exemples, une modification qui devrait etre transparente est le changement de la structure de donnee pour rendre la recherche de la charge la plus proche ou des charges visibles dans une fenetre plus efficace.
justement il me semble que ma représentation encapsule la liste...
Mais pourquoi ne serais-ce pas une "dequeu", ou un "vector" ?
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
noone@nowhere.com wrote:
Il me semble que rendre le fait que ta representation actuelle est une
liste *n'est pas* un bon choix. Par exemples, une modification qui
devrait etre transparente est le changement de la structure de donnee
pour rendre la recherche de la charge la plus proche ou des charges
visibles dans une fenetre plus efficace.
justement il me semble que ma représentation encapsule la liste...
Mais pourquoi ne serais-ce pas une "dequeu", ou un "vector" ?
Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
Il me semble que rendre le fait que ta representation actuelle est une liste *n'est pas* un bon choix. Par exemples, une modification qui devrait etre transparente est le changement de la structure de donnee pour rendre la recherche de la charge la plus proche ou des charges visibles dans une fenetre plus efficace.
justement il me semble que ma représentation encapsule la liste...
Mais pourquoi ne serais-ce pas une "dequeu", ou un "vector" ?
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
