Je suis débutant et étudiant en C++ et je ne m'aîtrise pas tellement les
bases. J'ai beau regarder dans mes bouquins, je me bute à un mur. Voilà que
j'ai un exercice à faire et je sollicite votre aide.
1)
Je dois écrire un programme qui définit une classe Point, et 2 classes qui
hérite de Point, Carré et Cube.
2)
L'exercice doit également être fait selon la Composition.
(*) En fait, je n'aurais vraissemblablement pas de classe Carre mais simplement une classe Rectangle que j'utiliserais aussi pour les carres (mais tout depend du contexte, en particulier si on a les deux -- Carre et Rectangle -- faut-il que Carre herite de Rectangle? -- apres tout un Carre *est un* Rectangle
Pas trop au sens LSP (et essentialiste) du terme être. On peut appliquer à un rectangle des opérations qui n'ont pas de sens sur un carré. Par exemple setRatio.
-- que Rectangle herite de Carre? -- apres tout il lui faut un champs de moins --
J'ai un peu de mal à voir la vertue de cette approche purement basée sur l'implémentation. Et puis, que signifie une fonction setCôté pour un rectangle ?
Nous sommes a peu pres d'accord. Mais pour preciser mon point de vue sur ce point que je pense que seules les operations pertinentes doivent etre considerees (et donc qu'il n'est pas impossible qu'on choississe a bon escient l'un ou l'autre des heritages bien que je n'ai pas d'exemple ou c'est le cas sous la main).
qu'ils soient independants?, a moins qu'avoir un mecanisme plus general de contraintes et qu'il n'y ait pas de Carre mais simplement des Rectangle contraints ne soit reellement la solution?).
J'avais vu une autre proposition que j'avais trouvée sympa :
Faire une classe RectangleConstant dont dérive Carré (ou CarréConstant puis Carré) et Rectangle.
A ce niveau, il faut voir le domaine (si Figure doit pouvoir accepter un changement de position ou une homothetie pour un editeur graphique par exemple, RectangleConstant me semble bizarre comme descendant de Figure -- note que dans ce cas la possibilite de transformation differente suivant les axes milite pour ne pas avoir de classe Carre: etre un carre si ca a une importance est alors une propriete d'un rectangle donne a un moment donne).
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:
(*) En fait, je n'aurais vraissemblablement pas de classe Carre mais
simplement une classe Rectangle que j'utiliserais aussi pour les
carres (mais tout depend du contexte, en particulier si on a les deux
-- Carre et Rectangle -- faut-il que Carre herite de Rectangle? --
apres tout un Carre *est un* Rectangle
Pas trop au sens LSP (et essentialiste) du terme être. On peut
appliquer à un rectangle des opérations qui n'ont pas de sens sur un
carré. Par exemple setRatio.
-- que Rectangle herite de
Carre? -- apres tout il lui faut un champs de moins --
J'ai un peu de mal à voir la vertue de cette approche purement basée sur
l'implémentation. Et puis, que signifie une fonction setCôté pour un
rectangle ?
Nous sommes a peu pres d'accord. Mais pour preciser mon point de vue
sur ce point que je pense que seules les operations pertinentes
doivent etre considerees (et donc qu'il n'est pas impossible qu'on
choississe a bon escient l'un ou l'autre des heritages bien que je
n'ai pas d'exemple ou c'est le cas sous la main).
qu'ils soient independants?, a moins qu'avoir un mecanisme plus
general de contraintes et qu'il n'y ait pas de Carre mais
simplement des Rectangle contraints ne soit reellement la
solution?).
J'avais vu une autre proposition que j'avais trouvée sympa :
Faire une classe RectangleConstant dont dérive Carré (ou
CarréConstant puis Carré) et Rectangle.
A ce niveau, il faut voir le domaine (si Figure doit pouvoir accepter
un changement de position ou une homothetie pour un editeur graphique
par exemple, RectangleConstant me semble bizarre comme descendant de
Figure -- note que dans ce cas la possibilite de transformation
differente suivant les axes milite pour ne pas avoir de classe Carre:
etre un carre si ca a une importance est alors une propriete d'un
rectangle donne a un moment donne).
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
(*) En fait, je n'aurais vraissemblablement pas de classe Carre mais simplement une classe Rectangle que j'utiliserais aussi pour les carres (mais tout depend du contexte, en particulier si on a les deux -- Carre et Rectangle -- faut-il que Carre herite de Rectangle? -- apres tout un Carre *est un* Rectangle
Pas trop au sens LSP (et essentialiste) du terme être. On peut appliquer à un rectangle des opérations qui n'ont pas de sens sur un carré. Par exemple setRatio.
-- que Rectangle herite de Carre? -- apres tout il lui faut un champs de moins --
J'ai un peu de mal à voir la vertue de cette approche purement basée sur l'implémentation. Et puis, que signifie une fonction setCôté pour un rectangle ?
Nous sommes a peu pres d'accord. Mais pour preciser mon point de vue sur ce point que je pense que seules les operations pertinentes doivent etre considerees (et donc qu'il n'est pas impossible qu'on choississe a bon escient l'un ou l'autre des heritages bien que je n'ai pas d'exemple ou c'est le cas sous la main).
qu'ils soient independants?, a moins qu'avoir un mecanisme plus general de contraintes et qu'il n'y ait pas de Carre mais simplement des Rectangle contraints ne soit reellement la solution?).
J'avais vu une autre proposition que j'avais trouvée sympa :
Faire une classe RectangleConstant dont dérive Carré (ou CarréConstant puis Carré) et Rectangle.
A ce niveau, il faut voir le domaine (si Figure doit pouvoir accepter un changement de position ou une homothetie pour un editeur graphique par exemple, RectangleConstant me semble bizarre comme descendant de Figure -- note que dans ce cas la possibilite de transformation differente suivant les axes milite pour ne pas avoir de classe Carre: etre un carre si ca a une importance est alors une propriete d'un rectangle donne a un moment donne).
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Stan
"Fabien LE LEZ" a écrit dans le message de news:
On Wed, 3 Aug 2005 14:20:46 +0200, "Stan" :
D'un point de vue "géométrique" un carré n'est pas vraiment un cas particulier de point, pourtant, ce type de relation ( Point : Carre ) n'est pas une hérésie.
Je trouve cette hiérarchie très perturbante, et franchement, je me refuserais à l'implémenter.
Maintenant, est-ce une hérésie ? Je ne sais pas.
Mais note que ça peut être dangereux.
Oui. D'ailleurs même une hiérachie bien conçue peut recéler des piéges lors de l'implémentation.
Ainsi, la fonction
bool Disjoints (Carre const&, Point const&);
est très vraisemblablement incorrecte si elle n'est pas accompagnée d'une fonction
bool Disjoints (Carre const&, Carre const&);
Que sont censées faire ces fonctions ?
-- -Stan
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de news:
61f2f1584kr9j9qk31j6607kultclf5hs8@4ax.com...
On Wed, 3 Aug 2005 14:20:46 +0200, "Stan" :
D'un point de vue "géométrique" un carré n'est pas vraiment un cas
particulier de point,
pourtant, ce type de relation ( Point : Carre ) n'est pas une hérésie.
Je trouve cette hiérarchie très perturbante, et franchement, je me
refuserais à l'implémenter.
Maintenant, est-ce une hérésie ? Je ne sais pas.
Mais note que ça peut être dangereux.
Oui. D'ailleurs même une hiérachie bien conçue
peut recéler des piéges lors de l'implémentation.
Ainsi, la fonction
bool Disjoints (Carre const&, Point const&);
est très vraisemblablement incorrecte si elle n'est pas accompagnée
d'une fonction
D'un point de vue "géométrique" un carré n'est pas vraiment un cas particulier de point, pourtant, ce type de relation ( Point : Carre ) n'est pas une hérésie.
Je trouve cette hiérarchie très perturbante, et franchement, je me refuserais à l'implémenter.
Maintenant, est-ce une hérésie ? Je ne sais pas.
Mais note que ça peut être dangereux.
Oui. D'ailleurs même une hiérachie bien conçue peut recéler des piéges lors de l'implémentation.
Ainsi, la fonction
bool Disjoints (Carre const&, Point const&);
est très vraisemblablement incorrecte si elle n'est pas accompagnée d'une fonction
bool Disjoints (Carre const&, Carre const&);
Que sont censées faire ces fonctions ?
-- -Stan
Fabien LE LEZ
On Thu, 4 Aug 2005 09:49:26 +0200, "Stan" ( remove the dots )>:
Que sont censées faire ces fonctions ?
Retourner true si les deux arguments (considérés comme figures géométriques) sont disjoints.
bool Disjoints (Carre const& c, Point const& p) { bool le_point_est_hors_du_carre p.x < c.gauche() || p.y < c.haut() || ...; /* L'algo n'a pas vraiment d'importance pour mon propos... */
return le_point_est_hors_du_carre; }
Cette fonction fonctionne parfaitement... sauf qu'un Carre étant un Point, la fonction en question sera a priori appelée, à tort, dans le code suivant :
Carre c1 (...); Carre c2 (...); if (Disjoints (c1,c2)) { cout << "Les carrés c1 et c2 ne se touchent pas." << endl; }
On Thu, 4 Aug 2005 09:49:26 +0200, "Stan" <z.y.l.o.g@wanadoo.fr (
remove the dots )>:
Que sont censées faire ces fonctions ?
Retourner true si les deux arguments (considérés comme figures
géométriques) sont disjoints.
bool Disjoints (Carre const& c, Point const& p)
{
bool le_point_est_hors_du_carre p.x < c.gauche() || p.y < c.haut() || ...; /* L'algo n'a
pas vraiment d'importance pour mon propos... */
return le_point_est_hors_du_carre;
}
Cette fonction fonctionne parfaitement... sauf qu'un Carre étant un
Point, la fonction en question sera a priori appelée, à tort, dans le
code suivant :
Carre c1 (...);
Carre c2 (...);
if (Disjoints (c1,c2))
{
cout << "Les carrés c1 et c2 ne se touchent pas." << endl;
}
On Thu, 4 Aug 2005 09:49:26 +0200, "Stan" ( remove the dots )>:
Que sont censées faire ces fonctions ?
Retourner true si les deux arguments (considérés comme figures géométriques) sont disjoints.
bool Disjoints (Carre const& c, Point const& p) { bool le_point_est_hors_du_carre p.x < c.gauche() || p.y < c.haut() || ...; /* L'algo n'a pas vraiment d'importance pour mon propos... */
return le_point_est_hors_du_carre; }
Cette fonction fonctionne parfaitement... sauf qu'un Carre étant un Point, la fonction en question sera a priori appelée, à tort, dans le code suivant :
Carre c1 (...); Carre c2 (...); if (Disjoints (c1,c2)) { cout << "Les carrés c1 et c2 ne se touchent pas." << endl; }
Stan
"Fabien LE LEZ" a écrit dans le message de news:
On Thu, 4 Aug 2005 09:49:26 +0200, "Stan" ( remove the dots )>:
Que sont censées faire ces fonctions ?
Retourner true si les deux arguments (considérés comme figures géométriques) sont disjoints.
bool Disjoints (Carre const& c, Point const& p) { bool le_point_est_hors_du_carre > p.x < c.gauche() || p.y < c.haut() || ...; /* L'algo n'a pas vraiment d'importance pour mon propos... */
return le_point_est_hors_du_carre; }
Cette fonction fonctionne parfaitement... sauf qu'un Carre étant un Point, la fonction en question sera a priori appelée, à tort, dans le
Non, un carré n'est pas un point, il est positionné depuis ce point. La fonction d'affichage permet à l'utilisateur de le comprendre.
code suivant :
Carre c1 (...); Carre c2 (...); if (Disjoints (c1,c2)) { cout << "Les carrés c1 et c2 ne se touchent pas." << endl; }
Ton approche me surprend beaucoup ( pas péjoratif ). Telle qu'elle est faite, comment la Disjoint peut-elle être générique ? Comment fait-tu pour tester un polygone, notamment si celui si est concave ?
Dans le même ordre d'idée, pourquoi ne pas prévoir une fonction virtuelle Disjoint dans Point qui, mathématiquement, n'est pas absurbe (un point peut être justaposé à un autre ) ?
Ne crois pas que je cherche la p'tite bête, je cherche à comparer nos approches ;-)
-- -Stan
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de news:
2kr3f1labr4tjsskbh26hij0t9hb6lg81g@4ax.com...
On Thu, 4 Aug 2005 09:49:26 +0200, "Stan" <z.y.l.o.g@wanadoo.fr (
remove the dots )>:
Que sont censées faire ces fonctions ?
Retourner true si les deux arguments (considérés comme figures
géométriques) sont disjoints.
bool Disjoints (Carre const& c, Point const& p)
{
bool le_point_est_hors_du_carre > p.x < c.gauche() || p.y < c.haut() || ...; /* L'algo n'a
pas vraiment d'importance pour mon propos... */
return le_point_est_hors_du_carre;
}
Cette fonction fonctionne parfaitement... sauf qu'un Carre étant un
Point, la fonction en question sera a priori appelée, à tort, dans le
Non, un carré n'est pas un point, il est positionné depuis ce point.
La fonction d'affichage permet à l'utilisateur de le comprendre.
code suivant :
Carre c1 (...);
Carre c2 (...);
if (Disjoints (c1,c2))
{
cout << "Les carrés c1 et c2 ne se touchent pas." << endl;
}
Ton approche me surprend beaucoup ( pas péjoratif ).
Telle qu'elle est faite, comment la Disjoint peut-elle être générique ?
Comment fait-tu pour tester un polygone, notamment si celui si est concave ?
Dans le même ordre d'idée, pourquoi ne pas prévoir une fonction virtuelle
Disjoint dans Point qui, mathématiquement, n'est pas absurbe (un point peut
être justaposé
à un autre ) ?
Ne crois pas que je cherche la p'tite bête, je cherche à comparer nos
approches ;-)
On Thu, 4 Aug 2005 09:49:26 +0200, "Stan" ( remove the dots )>:
Que sont censées faire ces fonctions ?
Retourner true si les deux arguments (considérés comme figures géométriques) sont disjoints.
bool Disjoints (Carre const& c, Point const& p) { bool le_point_est_hors_du_carre > p.x < c.gauche() || p.y < c.haut() || ...; /* L'algo n'a pas vraiment d'importance pour mon propos... */
return le_point_est_hors_du_carre; }
Cette fonction fonctionne parfaitement... sauf qu'un Carre étant un Point, la fonction en question sera a priori appelée, à tort, dans le
Non, un carré n'est pas un point, il est positionné depuis ce point. La fonction d'affichage permet à l'utilisateur de le comprendre.
code suivant :
Carre c1 (...); Carre c2 (...); if (Disjoints (c1,c2)) { cout << "Les carrés c1 et c2 ne se touchent pas." << endl; }
Ton approche me surprend beaucoup ( pas péjoratif ). Telle qu'elle est faite, comment la Disjoint peut-elle être générique ? Comment fait-tu pour tester un polygone, notamment si celui si est concave ?
Dans le même ordre d'idée, pourquoi ne pas prévoir une fonction virtuelle Disjoint dans Point qui, mathématiquement, n'est pas absurbe (un point peut être justaposé à un autre ) ?
Ne crois pas que je cherche la p'tite bête, je cherche à comparer nos approches ;-)
-- -Stan
Fabien LE LEZ
On Thu, 4 Aug 2005 13:15:52 +0200, "Stan" ( remove the dots )>:
Telle qu'elle est faite, comment la Disjoint peut-elle être générique ?
Elle ne l'est pas : elle prend un Carre en premier argument, et un Point en deuxième argument. Le problème, c'est que Carre hérite de Point, donc tu peux mettre un Carre en tout endroit où un Point convient. C'est pour ça que je dis que tout objet de classe Carre est un objet de classe Point. L'héritage est un couplage très fort.
Dans le même ordre d'idée, pourquoi ne pas prévoir une fonction virtuelle Disjoint dans Point qui, mathématiquement, n'est pas absurbe
La fonction Disjoint n'est qu'un exemple. Un autre exemple, plus artificiel :
void f (Point const& p) { cout << "L'argument passé est un Point" << endl; }
int main() { Carre un_carre; f (un_carre); }
On Thu, 4 Aug 2005 13:15:52 +0200, "Stan" <z.y.l.o.g@wanadoo.fr (
remove the dots )>:
Telle qu'elle est faite, comment la Disjoint peut-elle être générique ?
Elle ne l'est pas : elle prend un Carre en premier argument, et un
Point en deuxième argument.
Le problème, c'est que Carre hérite de Point, donc tu peux mettre un
Carre en tout endroit où un Point convient.
C'est pour ça que je dis que tout objet de classe Carre est un objet
de classe Point. L'héritage est un couplage très fort.
Dans le même ordre d'idée, pourquoi ne pas prévoir une fonction virtuelle
Disjoint dans Point qui, mathématiquement, n'est pas absurbe
La fonction Disjoint n'est qu'un exemple.
Un autre exemple, plus artificiel :
void f (Point const& p)
{
cout << "L'argument passé est un Point" << endl;
}
On Thu, 4 Aug 2005 13:15:52 +0200, "Stan" ( remove the dots )>:
Telle qu'elle est faite, comment la Disjoint peut-elle être générique ?
Elle ne l'est pas : elle prend un Carre en premier argument, et un Point en deuxième argument. Le problème, c'est que Carre hérite de Point, donc tu peux mettre un Carre en tout endroit où un Point convient. C'est pour ça que je dis que tout objet de classe Carre est un objet de classe Point. L'héritage est un couplage très fort.
Dans le même ordre d'idée, pourquoi ne pas prévoir une fonction virtuelle Disjoint dans Point qui, mathématiquement, n'est pas absurbe
La fonction Disjoint n'est qu'un exemple. Un autre exemple, plus artificiel :
void f (Point const& p) { cout << "L'argument passé est un Point" << endl; }
int main() { Carre un_carre; f (un_carre); }
Stan
"Fabien LE LEZ" a écrit dans le message de news:
Dans le même ordre d'idée, pourquoi ne pas prévoir une fonction virtuelle Disjoint dans Point qui, mathématiquement, n'est pas absurbe
La fonction Disjoint n'est qu'un exemple. Un autre exemple, plus artificiel :
void f (Point const& p) { cout << "L'argument passé est un Point" << endl; }
int main() { Carre un_carre; f (un_carre); }
Ton compilateur te permet de faire cela ?
-- -Stan
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de news:
slc5f11su537qose13rjgk0tp0mr3vl7ij@4ax.com...
Dans le même ordre d'idée, pourquoi ne pas prévoir une fonction virtuelle
Disjoint dans Point qui, mathématiquement, n'est pas absurbe
La fonction Disjoint n'est qu'un exemple.
Un autre exemple, plus artificiel :
void f (Point const& p)
{
cout << "L'argument passé est un Point" << endl;
}
Dans le même ordre d'idée, pourquoi ne pas prévoir une fonction virtuelle Disjoint dans Point qui, mathématiquement, n'est pas absurbe
La fonction Disjoint n'est qu'un exemple. Un autre exemple, plus artificiel :
void f (Point const& p) { cout << "L'argument passé est un Point" << endl; }
int main() { Carre un_carre; f (un_carre); }
Ton compilateur te permet de faire cela ?
-- -Stan
Fabien LE LEZ
On 03 Aug 2005 14:56:44 +0200, Jean-Marc Bourguet :
Si tu te places sur le plan religieux (je veux dire dans l'optique d'un respect absolu et irreflechi d'une certaine methodologie de conception), c'est une heresie: on n'herite pas d'une classe concrete et Point en est une.
Qu'est-ce qu'une classe concrète exactement ? Une classe n'ayant pas de fonction virtuelle pure ?
Si c'est bien ça, j'ai de la chance d'être athée, sinon mon usage immodéré de hiérarchies de classes concrètes (voire de classes n'ayant aucune fonction virtuelle, à part le destructeur, et encore, pas toujours) m'assurerait une place en enfer...
On 03 Aug 2005 14:56:44 +0200, Jean-Marc Bourguet <jm@bourguet.org>:
Si tu te places sur le plan religieux (je veux dire dans l'optique
d'un respect absolu et irreflechi d'une certaine methodologie de
conception), c'est une heresie: on n'herite pas d'une classe concrete
et Point en est une.
Qu'est-ce qu'une classe concrète exactement ? Une classe n'ayant pas
de fonction virtuelle pure ?
Si c'est bien ça, j'ai de la chance d'être athée, sinon mon usage
immodéré de hiérarchies de classes concrètes (voire de classes n'ayant
aucune fonction virtuelle, à part le destructeur, et encore, pas
toujours) m'assurerait une place en enfer...
On 03 Aug 2005 14:56:44 +0200, Jean-Marc Bourguet :
Si tu te places sur le plan religieux (je veux dire dans l'optique d'un respect absolu et irreflechi d'une certaine methodologie de conception), c'est une heresie: on n'herite pas d'une classe concrete et Point en est une.
Qu'est-ce qu'une classe concrète exactement ? Une classe n'ayant pas de fonction virtuelle pure ?
Si c'est bien ça, j'ai de la chance d'être athée, sinon mon usage immodéré de hiérarchies de classes concrètes (voire de classes n'ayant aucune fonction virtuelle, à part le destructeur, et encore, pas toujours) m'assurerait une place en enfer...
kanze
Fabien LE LEZ wrote:
On 03 Aug 2005 14:56:44 +0200, Jean-Marc Bourguet :
Si tu te places sur le plan religieux (je veux dire dans l'optique d'un respect absolu et irreflechi d'une certaine methodologie de conception), c'est une heresie: on n'herite pas d'une classe concrete et Point en est une.
Qu'est-ce qu'une classe concrète exactement ? Une classe n'ayant pas de fonction virtuelle pure ?
Formellement, concrète est le contraire d'abstraite. Donc, effectivement, une class n'ayant pas de fonction virtuelle.
Dans ce contexte-ci, en revanche, Scott Meyers, au moins, l'utilise avec une signification un peu plus lache : c'est une classe avec aucun membre données.
En fait, je ne sais pas si c'est une bonne règle. Si on considère le modèle template, par exemple...
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On 03 Aug 2005 14:56:44 +0200, Jean-Marc Bourguet <jm@bourguet.org>:
Si tu te places sur le plan religieux (je veux dire dans
l'optique d'un respect absolu et irreflechi d'une certaine
methodologie de conception), c'est une heresie: on n'herite
pas d'une classe concrete et Point en est une.
Qu'est-ce qu'une classe concrète exactement ? Une classe
n'ayant pas de fonction virtuelle pure ?
Formellement, concrète est le contraire d'abstraite. Donc,
effectivement, une class n'ayant pas de fonction virtuelle.
Dans ce contexte-ci, en revanche, Scott Meyers, au moins,
l'utilise avec une signification un peu plus lache : c'est une
classe avec aucun membre données.
En fait, je ne sais pas si c'est une bonne règle. Si on
considère le modèle template, par exemple...
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On 03 Aug 2005 14:56:44 +0200, Jean-Marc Bourguet :
Si tu te places sur le plan religieux (je veux dire dans l'optique d'un respect absolu et irreflechi d'une certaine methodologie de conception), c'est une heresie: on n'herite pas d'une classe concrete et Point en est une.
Qu'est-ce qu'une classe concrète exactement ? Une classe n'ayant pas de fonction virtuelle pure ?
Formellement, concrète est le contraire d'abstraite. Donc, effectivement, une class n'ayant pas de fonction virtuelle.
Dans ce contexte-ci, en revanche, Scott Meyers, au moins, l'utilise avec une signification un peu plus lache : c'est une classe avec aucun membre données.
En fait, je ne sais pas si c'est une bonne règle. Si on considère le modèle template, par exemple...
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Michel Michaud
Dans le message ,
Fabien LE LEZ wrote:
Qu'est-ce qu'une classe concrète exactement ? Une classe n'ayant pas de fonction virtuelle pure ?
Formellement, concrète est le contraire d'abstraite. Donc, effectivement, une class n'ayant pas de fonction virtuelle.
Dans ce contexte-ci, en revanche, Scott Meyers, au moins, l'utilise avec une signification un peu plus lache : c'est une classe avec aucun membre données.
Je suppose que tu continuais à parler de ce qu'est une classe abstraite... Je ne crois pas que c'est une définition donnée par Scott, ni ce qu'il pense. En fait, j'en suis sûr, car je lui ai déjà demandé son avis sur ce point précis ! Et je crois que c'est parce que tu avais déjà prétendu que c'est ce qu'il disait...
En fait, je ne sais pas si c'est une bonne règle. Si on considère le modèle template, par exemple...
Je crois qu'il est assez fréquent qu'une classe abstraite n'ait pas de donnée membre. Mais c'est une observation, pas une règle à suivre.
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans le message 1123247566.232461.318970@g14g2000cwa.googlegroups.com,
Fabien LE LEZ wrote:
Qu'est-ce qu'une classe concrète exactement ? Une classe
n'ayant pas de fonction virtuelle pure ?
Formellement, concrète est le contraire d'abstraite. Donc,
effectivement, une class n'ayant pas de fonction virtuelle.
Dans ce contexte-ci, en revanche, Scott Meyers, au moins,
l'utilise avec une signification un peu plus lache : c'est une
classe avec aucun membre données.
Je suppose que tu continuais à parler de ce qu'est une classe
abstraite... Je ne crois pas que c'est une définition donnée par
Scott, ni ce qu'il pense. En fait, j'en suis sûr, car je lui ai
déjà demandé son avis sur ce point précis ! Et je crois que c'est
parce que tu avais déjà prétendu que c'est ce qu'il disait...
En fait, je ne sais pas si c'est une bonne règle. Si on
considère le modèle template, par exemple...
Je crois qu'il est assez fréquent qu'une classe abstraite n'ait
pas de donnée membre. Mais c'est une observation, pas une règle
à suivre.
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Qu'est-ce qu'une classe concrète exactement ? Une classe n'ayant pas de fonction virtuelle pure ?
Formellement, concrète est le contraire d'abstraite. Donc, effectivement, une class n'ayant pas de fonction virtuelle.
Dans ce contexte-ci, en revanche, Scott Meyers, au moins, l'utilise avec une signification un peu plus lache : c'est une classe avec aucun membre données.
Je suppose que tu continuais à parler de ce qu'est une classe abstraite... Je ne crois pas que c'est une définition donnée par Scott, ni ce qu'il pense. En fait, j'en suis sûr, car je lui ai déjà demandé son avis sur ce point précis ! Et je crois que c'est parce que tu avais déjà prétendu que c'est ce qu'il disait...
En fait, je ne sais pas si c'est une bonne règle. Si on considère le modèle template, par exemple...
Je crois qu'il est assez fréquent qu'une classe abstraite n'ait pas de donnée membre. Mais c'est une observation, pas une règle à suivre.
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Michel Michaud
Dans le message ,
Si c'est bien ça, j'ai de la chance d'être athée, sinon mon usage immodéré de hiérarchies de classes concrètes (voire de classes n'ayant aucune fonction virtuelle, à part le destructeur, et encore, pas toujours) m'assurerait une place en enfer...
La règle de Scott Meyers est « Make Non-Leaf Classes Abstract ». Elle est dans More Effective C++ que tu as évidemment lu, non ?
La règle sert à prévenir des problèmes et aide à avoir un bon design. Mais c'est clairement une règle C++ plus qu'un règle OO en général, ce qui peut laisser supposer que des exceptions raisonnables sont plus que probables.
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans le message hei6f1l6qbkfmbahdl9lqjevf6m2rk71eu@4ax.com,
Si c'est bien ça, j'ai de la chance d'être athée, sinon mon usage
immodéré de hiérarchies de classes concrètes (voire de classes
n'ayant aucune fonction virtuelle, à part le destructeur, et
encore, pas toujours) m'assurerait une place en enfer...
La règle de Scott Meyers est « Make Non-Leaf Classes Abstract ».
Elle est dans More Effective C++ que tu as évidemment lu, non ?
La règle sert à prévenir des problèmes et aide à avoir un bon
design. Mais c'est clairement une règle C++ plus qu'un règle
OO en général, ce qui peut laisser supposer que des exceptions
raisonnables sont plus que probables.
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Si c'est bien ça, j'ai de la chance d'être athée, sinon mon usage immodéré de hiérarchies de classes concrètes (voire de classes n'ayant aucune fonction virtuelle, à part le destructeur, et encore, pas toujours) m'assurerait une place en enfer...
La règle de Scott Meyers est « Make Non-Leaf Classes Abstract ». Elle est dans More Effective C++ que tu as évidemment lu, non ?
La règle sert à prévenir des problèmes et aide à avoir un bon design. Mais c'est clairement une règle C++ plus qu'un règle OO en général, ce qui peut laisser supposer que des exceptions raisonnables sont plus que probables.
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
