On 28 Jan, 11:53, Wykaaa wrote:Stan a écrit :On 28 jan, 00:09, Wykaaa wrote:[...]Quel est le plus évolutif ?
Où est ta différence valeur/comportement ?Même avec une conception objet du logiciel efficace,
à un moment donné, il te faudra bien implémenter
*un peu* d'algorithmie.Et là, tu peux dire ce que tu veux, pour être efficace (en
rapidité, lisibilité et maintenance), les enum, switch ou
if/else sont tout adaptés. Lorsque c'est bien, conçu, ce ne
pose aucun pb ( à l'echelle de l'algo évidemment).Mon exemple ne te parle-t-il pas ?
Et comment. Il montre bien le problème de ne pas utiliser un
enum. Utiliser des classes distinctes, comme tu as voulu faire,
signifie que les fonctions qui déterminent le jour doivent
connaître ton application.
l'encapsulation. Tandis que l'enum...
(Et en passant, est-ce que tu penses réelement qu'il faut que le
code prenne en compte la possibilité que le nombre de jours dans
la semaine change ? Il y a quand même des limites à la
généricité.)
Les switches sont une horreur pour la maintenance et les évolutions
quand on fait de l'objet alors que le polymorphisme rend les
"aiguillages" automatiques quand on ajoute des sous-classes.
Le polymorphisme est une horreur pour la maintenance quand
l'information décisive est calculée autre part que dans le code
applicatif.
On 28 Jan, 11:53, Wykaaa <wyk...@yahoo.fr> wrote:
Stan a écrit :
On 28 jan, 00:09, Wykaaa <wyk...@yahoo.fr> wrote:
[...]
Quel est le plus évolutif ?
Où est ta différence valeur/comportement ?
Même avec une conception objet du logiciel efficace,
à un moment donné, il te faudra bien implémenter
*un peu* d'algorithmie.
Et là, tu peux dire ce que tu veux, pour être efficace (en
rapidité, lisibilité et maintenance), les enum, switch ou
if/else sont tout adaptés. Lorsque c'est bien, conçu, ce ne
pose aucun pb ( à l'echelle de l'algo évidemment).
Mon exemple ne te parle-t-il pas ?
Et comment. Il montre bien le problème de ne pas utiliser un
enum. Utiliser des classes distinctes, comme tu as voulu faire,
signifie que les fonctions qui déterminent le jour doivent
connaître ton application.
l'encapsulation. Tandis que l'enum...
(Et en passant, est-ce que tu penses réelement qu'il faut que le
code prenne en compte la possibilité que le nombre de jours dans
la semaine change ? Il y a quand même des limites à la
généricité.)
Les switches sont une horreur pour la maintenance et les évolutions
quand on fait de l'objet alors que le polymorphisme rend les
"aiguillages" automatiques quand on ajoute des sous-classes.
Le polymorphisme est une horreur pour la maintenance quand
l'information décisive est calculée autre part que dans le code
applicatif.
On 28 Jan, 11:53, Wykaaa wrote:Stan a écrit :On 28 jan, 00:09, Wykaaa wrote:[...]Quel est le plus évolutif ?
Où est ta différence valeur/comportement ?Même avec une conception objet du logiciel efficace,
à un moment donné, il te faudra bien implémenter
*un peu* d'algorithmie.Et là, tu peux dire ce que tu veux, pour être efficace (en
rapidité, lisibilité et maintenance), les enum, switch ou
if/else sont tout adaptés. Lorsque c'est bien, conçu, ce ne
pose aucun pb ( à l'echelle de l'algo évidemment).Mon exemple ne te parle-t-il pas ?
Et comment. Il montre bien le problème de ne pas utiliser un
enum. Utiliser des classes distinctes, comme tu as voulu faire,
signifie que les fonctions qui déterminent le jour doivent
connaître ton application.
l'encapsulation. Tandis que l'enum...
(Et en passant, est-ce que tu penses réelement qu'il faut que le
code prenne en compte la possibilité que le nombre de jours dans
la semaine change ? Il y a quand même des limites à la
généricité.)
Les switches sont une horreur pour la maintenance et les évolutions
quand on fait de l'objet alors que le polymorphisme rend les
"aiguillages" automatiques quand on ajoute des sous-classes.
Le polymorphisme est une horreur pour la maintenance quand
l'information décisive est calculée autre part que dans le code
applicatif.
On 27 Jan, 23:09, Wykaaa wrote:James Kanze a écrit :On Jan 27, 7:45 pm, Wykaaa wrote:Marc Espie a écrit :
[...]Les variables non initialisees (et leur copain, les switch
sur un champ type) sont des symptomes de design faits par
des gens qui n'ont pas encore bien integre la conception
objet (ou qui, pour de basses questions de temps, n'ont pas
termine leur design).En approche objet, je n'utilise jamais des enums. Je passe
toujours par l'héritage.Étant donné que les deux sert à des buts complètement
différents, je ne vois pas le rapport. J'en utilise les deux.Non, il n'ont pas des buts différents.
Je regrette, mais ils n'ont aucun rapport immédiat. Il y a bien
queques cas où on pourrait se servir de l'un ou de l'autre, mais
ils sont assez rare. En général, au moins dans un langage comme
le C++ qui supporte les deux, c'est l'un ou l'autre qui
s'impose, selon le cas, et l'utilisation de l'autre donne un
programme nettement inférieur.Un enum, c'est une classe abstraite et il y a autant de
sous-classes que de valeurs dans l'enum.Sauf qu'un enum, ça n'a rien à voir avec une classe,
abstraite ou non. (Pour commencer, un enum, c'est une
valeur, et une classe abstraite suppose en général un
comportement et une identité. Tout à fait l'opposer d'un
enum.)Tu veux dire qu'un enum est une variable scalaire quand tu dis
"valeur"?
Exactement. C'est une valeur, au sens absolut du terme.Et un enum, ça a un comportement puisqu'on le gère avec des
switches...
Si tu veux faire des bêtises, effectivement, il n'y a rien dans
le langage qui te l'empêche. Mais des switch sur des enum, c'est
quand même des exceptions. Tout au plus, on fait un if sur une
valeur spéciale (genre OK), ou on se sert comme indice dans un
tableau (par exemple, pour récupérer le message à afficher).
Mais l'enum sert surtout à transporter l'information entre des
couches de programmation qui ne se connaissent pas, d'une façon
simple et efficace. Il transporte l'information ; il n'a pas de
comportement.
1) enumenum Jour {LUNDI, MARDI, MERCREDI, ...};
Jour j = ...;void travailler(Jour leJour)
{
switch(j)
{
case LUNDI : //faire ceci
case MARDI : //faire cela
case MERCREDI : //faire autre chose
...
}travailler(j);
N'est-ce pas une fonction qui décrit un comportement de l'enum ?2) polymorphismeclass Jour
{
public:
virtual void travailler()=0;
// éventuellement d'autres méthodes
}class Lundi
{
public:
virtual void travailler() {//faire ceci}
};
class Mardi
{
public:
virtual void travailler() {//faire cela}
};
class Mercredi
{
public:
virtual void travailler() {//faire autre chose}
};Jour j = new ...;j.travailler();Quel est le plus évolutif ?
Le premier, de loin. C'est un exemple type où l'enum convient,
et la classe polymorphique non. Parce que le code qui convertit
la date système en jour ne doit rien savoir de ton travailler,
même pas qu'il existe.
Ensuite, si tu as des dépendences dans le comportement, on
pourrait imaginer une hièrarchie qui les encapsule. Quelque
chose du genre :
class Activité
{
public:
virtual ~Activité();
virtual void travailler() = 0;
};
class ActivitéDeJourDeLaSemaine : public Activité ...
class ActivitéDeSamedi : public Activité ...
class ActivitéDeDimanche : public Activité ...
ActivitéFactory* dispatch[] > {
&activitéDeJourDeLaSemaineFactory,
&activitéDeJourDeLaSemaineFactory,
&activitéDeJourDeLaSemaineFactory,
&activitéDeJourDeLaSemaineFactory,
&activitéDeJourDeLaSemaineFactory,
&activitéDeSamediFactory,
&activitéDeDimancheFactory
};
std::auto_ptr< Activité >
getActivité( JourDeLaSemaine jour )
{
return dispatch[ jour ]->createInstance();
}
Évidemment, le jour qu'on change le nombre de jours dans la
semaine, il va falloir retoucher le tableau. Mais c'est une
risque acceptable, à mon avis. Et en fait, ça serait
probablement toujours moins de travail que ta solution, parce
qu'on peut supposer que le jour qu'on ajoute, c'est un jour de
semaine, et donc, la classe nécessaire est déjà écrite.
Dans l'ensemble, je crois que tu as bien mal choisi ton exemple.
On 27 Jan, 23:09, Wykaaa <wyk...@yahoo.fr> wrote:
James Kanze a écrit :
On Jan 27, 7:45 pm, Wykaaa <wyk...@yahoo.fr> wrote:
Marc Espie a écrit :
[...]
Les variables non initialisees (et leur copain, les switch
sur un champ type) sont des symptomes de design faits par
des gens qui n'ont pas encore bien integre la conception
objet (ou qui, pour de basses questions de temps, n'ont pas
termine leur design).
En approche objet, je n'utilise jamais des enums. Je passe
toujours par l'héritage.
Étant donné que les deux sert à des buts complètement
différents, je ne vois pas le rapport. J'en utilise les deux.
Non, il n'ont pas des buts différents.
Je regrette, mais ils n'ont aucun rapport immédiat. Il y a bien
queques cas où on pourrait se servir de l'un ou de l'autre, mais
ils sont assez rare. En général, au moins dans un langage comme
le C++ qui supporte les deux, c'est l'un ou l'autre qui
s'impose, selon le cas, et l'utilisation de l'autre donne un
programme nettement inférieur.
Un enum, c'est une classe abstraite et il y a autant de
sous-classes que de valeurs dans l'enum.
Sauf qu'un enum, ça n'a rien à voir avec une classe,
abstraite ou non. (Pour commencer, un enum, c'est une
valeur, et une classe abstraite suppose en général un
comportement et une identité. Tout à fait l'opposer d'un
enum.)
Tu veux dire qu'un enum est une variable scalaire quand tu dis
"valeur"?
Exactement. C'est une valeur, au sens absolut du terme.
Et un enum, ça a un comportement puisqu'on le gère avec des
switches...
Si tu veux faire des bêtises, effectivement, il n'y a rien dans
le langage qui te l'empêche. Mais des switch sur des enum, c'est
quand même des exceptions. Tout au plus, on fait un if sur une
valeur spéciale (genre OK), ou on se sert comme indice dans un
tableau (par exemple, pour récupérer le message à afficher).
Mais l'enum sert surtout à transporter l'information entre des
couches de programmation qui ne se connaissent pas, d'une façon
simple et efficace. Il transporte l'information ; il n'a pas de
comportement.
1) enum
enum Jour {LUNDI, MARDI, MERCREDI, ...};
Jour j = ...;
void travailler(Jour leJour)
{
switch(j)
{
case LUNDI : //faire ceci
case MARDI : //faire cela
case MERCREDI : //faire autre chose
...
}
travailler(j);
N'est-ce pas une fonction qui décrit un comportement de l'enum ?
2) polymorphisme
class Jour
{
public:
virtual void travailler()=0;
// éventuellement d'autres méthodes
}
class Lundi
{
public:
virtual void travailler() {//faire ceci}
};
class Mardi
{
public:
virtual void travailler() {//faire cela}
};
class Mercredi
{
public:
virtual void travailler() {//faire autre chose}
};
Jour j = new ...;
j.travailler();
Quel est le plus évolutif ?
Le premier, de loin. C'est un exemple type où l'enum convient,
et la classe polymorphique non. Parce que le code qui convertit
la date système en jour ne doit rien savoir de ton travailler,
même pas qu'il existe.
Ensuite, si tu as des dépendences dans le comportement, on
pourrait imaginer une hièrarchie qui les encapsule. Quelque
chose du genre :
class Activité
{
public:
virtual ~Activité();
virtual void travailler() = 0;
};
class ActivitéDeJourDeLaSemaine : public Activité ...
class ActivitéDeSamedi : public Activité ...
class ActivitéDeDimanche : public Activité ...
ActivitéFactory* dispatch[] > {
&activitéDeJourDeLaSemaineFactory,
&activitéDeJourDeLaSemaineFactory,
&activitéDeJourDeLaSemaineFactory,
&activitéDeJourDeLaSemaineFactory,
&activitéDeJourDeLaSemaineFactory,
&activitéDeSamediFactory,
&activitéDeDimancheFactory
};
std::auto_ptr< Activité >
getActivité( JourDeLaSemaine jour )
{
return dispatch[ jour ]->createInstance();
}
Évidemment, le jour qu'on change le nombre de jours dans la
semaine, il va falloir retoucher le tableau. Mais c'est une
risque acceptable, à mon avis. Et en fait, ça serait
probablement toujours moins de travail que ta solution, parce
qu'on peut supposer que le jour qu'on ajoute, c'est un jour de
semaine, et donc, la classe nécessaire est déjà écrite.
Dans l'ensemble, je crois que tu as bien mal choisi ton exemple.
On 27 Jan, 23:09, Wykaaa wrote:James Kanze a écrit :On Jan 27, 7:45 pm, Wykaaa wrote:Marc Espie a écrit :
[...]Les variables non initialisees (et leur copain, les switch
sur un champ type) sont des symptomes de design faits par
des gens qui n'ont pas encore bien integre la conception
objet (ou qui, pour de basses questions de temps, n'ont pas
termine leur design).En approche objet, je n'utilise jamais des enums. Je passe
toujours par l'héritage.Étant donné que les deux sert à des buts complètement
différents, je ne vois pas le rapport. J'en utilise les deux.Non, il n'ont pas des buts différents.
Je regrette, mais ils n'ont aucun rapport immédiat. Il y a bien
queques cas où on pourrait se servir de l'un ou de l'autre, mais
ils sont assez rare. En général, au moins dans un langage comme
le C++ qui supporte les deux, c'est l'un ou l'autre qui
s'impose, selon le cas, et l'utilisation de l'autre donne un
programme nettement inférieur.Un enum, c'est une classe abstraite et il y a autant de
sous-classes que de valeurs dans l'enum.Sauf qu'un enum, ça n'a rien à voir avec une classe,
abstraite ou non. (Pour commencer, un enum, c'est une
valeur, et une classe abstraite suppose en général un
comportement et une identité. Tout à fait l'opposer d'un
enum.)Tu veux dire qu'un enum est une variable scalaire quand tu dis
"valeur"?
Exactement. C'est une valeur, au sens absolut du terme.Et un enum, ça a un comportement puisqu'on le gère avec des
switches...
Si tu veux faire des bêtises, effectivement, il n'y a rien dans
le langage qui te l'empêche. Mais des switch sur des enum, c'est
quand même des exceptions. Tout au plus, on fait un if sur une
valeur spéciale (genre OK), ou on se sert comme indice dans un
tableau (par exemple, pour récupérer le message à afficher).
Mais l'enum sert surtout à transporter l'information entre des
couches de programmation qui ne se connaissent pas, d'une façon
simple et efficace. Il transporte l'information ; il n'a pas de
comportement.
1) enumenum Jour {LUNDI, MARDI, MERCREDI, ...};
Jour j = ...;void travailler(Jour leJour)
{
switch(j)
{
case LUNDI : //faire ceci
case MARDI : //faire cela
case MERCREDI : //faire autre chose
...
}travailler(j);
N'est-ce pas une fonction qui décrit un comportement de l'enum ?2) polymorphismeclass Jour
{
public:
virtual void travailler()=0;
// éventuellement d'autres méthodes
}class Lundi
{
public:
virtual void travailler() {//faire ceci}
};
class Mardi
{
public:
virtual void travailler() {//faire cela}
};
class Mercredi
{
public:
virtual void travailler() {//faire autre chose}
};Jour j = new ...;j.travailler();Quel est le plus évolutif ?
Le premier, de loin. C'est un exemple type où l'enum convient,
et la classe polymorphique non. Parce que le code qui convertit
la date système en jour ne doit rien savoir de ton travailler,
même pas qu'il existe.
Ensuite, si tu as des dépendences dans le comportement, on
pourrait imaginer une hièrarchie qui les encapsule. Quelque
chose du genre :
class Activité
{
public:
virtual ~Activité();
virtual void travailler() = 0;
};
class ActivitéDeJourDeLaSemaine : public Activité ...
class ActivitéDeSamedi : public Activité ...
class ActivitéDeDimanche : public Activité ...
ActivitéFactory* dispatch[] > {
&activitéDeJourDeLaSemaineFactory,
&activitéDeJourDeLaSemaineFactory,
&activitéDeJourDeLaSemaineFactory,
&activitéDeJourDeLaSemaineFactory,
&activitéDeJourDeLaSemaineFactory,
&activitéDeSamediFactory,
&activitéDeDimancheFactory
};
std::auto_ptr< Activité >
getActivité( JourDeLaSemaine jour )
{
return dispatch[ jour ]->createInstance();
}
Évidemment, le jour qu'on change le nombre de jours dans la
semaine, il va falloir retoucher le tableau. Mais c'est une
risque acceptable, à mon avis. Et en fait, ça serait
probablement toujours moins de travail que ta solution, parce
qu'on peut supposer que le jour qu'on ajoute, c'est un jour de
semaine, et donc, la classe nécessaire est déjà écrite.
Dans l'ensemble, je crois que tu as bien mal choisi ton exemple.
Marc Espie a écrit :
C'est l'effet de la programmation de "style C" en C++... et ça
correspond à ce que je dis dans un autre post de ce fil : programmer en
style C avec C++, c'est pire que de rester en C et on le voit avec éclat
ici.
La classe Move est à revoir totalement et, je le répète,
"promotion" n'a rien à faire ici.
Les variables non initialisees (et leur copain, les switch sur un
champ type)
sont des symptomes de design faits par des gens qui n'ont pas encore bien
integre la conception objet (ou qui, pour de basses questions de temps,
n'ont pas termine leur design).
En approche objet, je n'utilise jamais des enums. Je passe toujours par
l'héritage.
Un enum, c'est une classe abstraite et il y a autant de sous-classes que
de valeurs dans l'enum.
Marc Espie a écrit :
C'est l'effet de la programmation de "style C" en C++... et ça
correspond à ce que je dis dans un autre post de ce fil : programmer en
style C avec C++, c'est pire que de rester en C et on le voit avec éclat
ici.
La classe Move est à revoir totalement et, je le répète,
"promotion" n'a rien à faire ici.
Les variables non initialisees (et leur copain, les switch sur un
champ type)
sont des symptomes de design faits par des gens qui n'ont pas encore bien
integre la conception objet (ou qui, pour de basses questions de temps,
n'ont pas termine leur design).
En approche objet, je n'utilise jamais des enums. Je passe toujours par
l'héritage.
Un enum, c'est une classe abstraite et il y a autant de sous-classes que
de valeurs dans l'enum.
Marc Espie a écrit :
C'est l'effet de la programmation de "style C" en C++... et ça
correspond à ce que je dis dans un autre post de ce fil : programmer en
style C avec C++, c'est pire que de rester en C et on le voit avec éclat
ici.
La classe Move est à revoir totalement et, je le répète,
"promotion" n'a rien à faire ici.
Les variables non initialisees (et leur copain, les switch sur un
champ type)
sont des symptomes de design faits par des gens qui n'ont pas encore bien
integre la conception objet (ou qui, pour de basses questions de temps,
n'ont pas termine leur design).
En approche objet, je n'utilise jamais des enums. Je passe toujours par
l'héritage.
Un enum, c'est une classe abstraite et il y a autant de sous-classes que
de valeurs dans l'enum.
Le 27/01/2010 20:45, Wykaaa a écrit :Marc Espie a écrit :C'est l'effet de la programmation de "style C" en C++... et ça
correspond à ce que je dis dans un autre post de ce fil : programmer en
style C avec C++, c'est pire que de rester en C et on le voit avec éclat
ici.
Moi qui croyais que le C++ était un langage multiparadigme.
La classe Move est à revoir totalement et, je le répète,
"promotion" n'a rien à faire ici.
Si.
Les variables non initialisees (et leur copain, les switch sur un
champ type)
sont des symptomes de design faits par des gens qui n'ont pas encore
bien
integre la conception objet (ou qui, pour de basses questions de temps,
n'ont pas termine leur design).
En approche objet, je n'utilise jamais des enums. Je passe toujours par
l'héritage.
Un enum, c'est une classe abstraite et il y a autant de sous-classes que
de valeurs dans l'enum.
Je dois avouer ne pas comprendre ce que vous voulez dire. En tout cas je
n'utilise pas spécialement les enums pour faire des switch.
Il y a effectivement un switch, mais il se fait sur une valeur entière,
et non un enum, "in_check" qui indique le nombre de pièces causant un
échec (0: pas d'échec, 1: échec simple, 2: échec double). Quant à mes
enum, il me servent de valeurs contenues dans des tableaux (échiquier,
listes de pièces), des variables ou passées à des fonctions. Ils sont
juste là pour rendre le code plus lisibles que la simple utilisation de
valeurs numériques. De plus, comme le typage C++ des enums est fort, ça
évite de prendre une couleur pour une pièce, ce que ne permet pas le C.
Ça permet de détecter des bêtise à la compilation. AMHA, on a plus
intérêt à utiliser des enums en C++ qu'en C, où ils n'apportent pas
grand chose de plus que des constantes, voire des macros.
Le 27/01/2010 20:45, Wykaaa a écrit :
Marc Espie a écrit :
C'est l'effet de la programmation de "style C" en C++... et ça
correspond à ce que je dis dans un autre post de ce fil : programmer en
style C avec C++, c'est pire que de rester en C et on le voit avec éclat
ici.
Moi qui croyais que le C++ était un langage multiparadigme.
La classe Move est à revoir totalement et, je le répète,
"promotion" n'a rien à faire ici.
Si.
Les variables non initialisees (et leur copain, les switch sur un
champ type)
sont des symptomes de design faits par des gens qui n'ont pas encore
bien
integre la conception objet (ou qui, pour de basses questions de temps,
n'ont pas termine leur design).
En approche objet, je n'utilise jamais des enums. Je passe toujours par
l'héritage.
Un enum, c'est une classe abstraite et il y a autant de sous-classes que
de valeurs dans l'enum.
Je dois avouer ne pas comprendre ce que vous voulez dire. En tout cas je
n'utilise pas spécialement les enums pour faire des switch.
Il y a effectivement un switch, mais il se fait sur une valeur entière,
et non un enum, "in_check" qui indique le nombre de pièces causant un
échec (0: pas d'échec, 1: échec simple, 2: échec double). Quant à mes
enum, il me servent de valeurs contenues dans des tableaux (échiquier,
listes de pièces), des variables ou passées à des fonctions. Ils sont
juste là pour rendre le code plus lisibles que la simple utilisation de
valeurs numériques. De plus, comme le typage C++ des enums est fort, ça
évite de prendre une couleur pour une pièce, ce que ne permet pas le C.
Ça permet de détecter des bêtise à la compilation. AMHA, on a plus
intérêt à utiliser des enums en C++ qu'en C, où ils n'apportent pas
grand chose de plus que des constantes, voire des macros.
Le 27/01/2010 20:45, Wykaaa a écrit :Marc Espie a écrit :C'est l'effet de la programmation de "style C" en C++... et ça
correspond à ce que je dis dans un autre post de ce fil : programmer en
style C avec C++, c'est pire que de rester en C et on le voit avec éclat
ici.
Moi qui croyais que le C++ était un langage multiparadigme.
La classe Move est à revoir totalement et, je le répète,
"promotion" n'a rien à faire ici.
Si.
Les variables non initialisees (et leur copain, les switch sur un
champ type)
sont des symptomes de design faits par des gens qui n'ont pas encore
bien
integre la conception objet (ou qui, pour de basses questions de temps,
n'ont pas termine leur design).
En approche objet, je n'utilise jamais des enums. Je passe toujours par
l'héritage.
Un enum, c'est une classe abstraite et il y a autant de sous-classes que
de valeurs dans l'enum.
Je dois avouer ne pas comprendre ce que vous voulez dire. En tout cas je
n'utilise pas spécialement les enums pour faire des switch.
Il y a effectivement un switch, mais il se fait sur une valeur entière,
et non un enum, "in_check" qui indique le nombre de pièces causant un
échec (0: pas d'échec, 1: échec simple, 2: échec double). Quant à mes
enum, il me servent de valeurs contenues dans des tableaux (échiquier,
listes de pièces), des variables ou passées à des fonctions. Ils sont
juste là pour rendre le code plus lisibles que la simple utilisation de
valeurs numériques. De plus, comme le typage C++ des enums est fort, ça
évite de prendre une couleur pour une pièce, ce que ne permet pas le C.
Ça permet de détecter des bêtise à la compilation. AMHA, on a plus
intérêt à utiliser des enums en C++ qu'en C, où ils n'apportent pas
grand chose de plus que des constantes, voire des macros.
Or quand dans une AbstractFactory , pour créer tes objets tu n'as
pas 10000 possibilités ;
tu peux utiliser un tableau associatif, ou bien un selecteur de type
if/else,
ou encore un switch + enum.
Pour des construction reposant sur un int, ce dernier choix est tout à
fait
acceptable.
Or quand dans une AbstractFactory , pour créer tes objets tu n'as
pas 10000 possibilités ;
tu peux utiliser un tableau associatif, ou bien un selecteur de type
if/else,
ou encore un switch + enum.
Pour des construction reposant sur un int, ce dernier choix est tout à
fait
acceptable.
Or quand dans une AbstractFactory , pour créer tes objets tu n'as
pas 10000 possibilités ;
tu peux utiliser un tableau associatif, ou bien un selecteur de type
if/else,
ou encore un switch + enum.
Pour des construction reposant sur un int, ce dernier choix est tout à
fait
acceptable.
Non, il est bien choisi sauf pour le cas où on va ajouter des
sous-classes. A moins qu'on change radicalement le calendrier en
inventant un nouveau jour comme jacadi :-) (Jacques est mon vrai
prénom...).
Non, il est bien choisi sauf pour le cas où on va ajouter des
sous-classes. A moins qu'on change radicalement le calendrier en
inventant un nouveau jour comme jacadi :-) (Jacques est mon vrai
prénom...).
Non, il est bien choisi sauf pour le cas où on va ajouter des
sous-classes. A moins qu'on change radicalement le calendrier en
inventant un nouveau jour comme jacadi :-) (Jacques est mon vrai
prénom...).
Stan a écrit :
> Or quand dans une AbstractFactory , pour créer tes objets tu n'as
> pas 10000 possibilités ;
> tu peux utiliser un tableau associatif, ou bien un selecteur de type
> if/else,
> ou encore un switch + enum.
> Pour des construction reposant sur un int, ce dernier choix est tout à
> fait
> acceptable.
Ce ne serait pas mieux d'utiliser la surcharge de fonction dans ce
cas là ? Par exemple :
struct factory
{
void create(machin * truc) ;
void create(autre_machin * truc) ;
} ;
Stan a écrit :
> Or quand dans une AbstractFactory , pour créer tes objets tu n'as
> pas 10000 possibilités ;
> tu peux utiliser un tableau associatif, ou bien un selecteur de type
> if/else,
> ou encore un switch + enum.
> Pour des construction reposant sur un int, ce dernier choix est tout à
> fait
> acceptable.
Ce ne serait pas mieux d'utiliser la surcharge de fonction dans ce
cas là ? Par exemple :
struct factory
{
void create(machin * truc) ;
void create(autre_machin * truc) ;
} ;
Stan a écrit :
> Or quand dans une AbstractFactory , pour créer tes objets tu n'as
> pas 10000 possibilités ;
> tu peux utiliser un tableau associatif, ou bien un selecteur de type
> if/else,
> ou encore un switch + enum.
> Pour des construction reposant sur un int, ce dernier choix est tout à
> fait
> acceptable.
Ce ne serait pas mieux d'utiliser la surcharge de fonction dans ce
cas là ? Par exemple :
struct factory
{
void create(machin * truc) ;
void create(autre_machin * truc) ;
} ;
James Kanze a crit :
> On 27 Jan, 22:26, Wykaaa wrote:
>> Stan a écrit :
>>> On 27 jan, 20:45, Wykaaa wrote:
>>>> En approche objet, je n'utilise jamais des enums. Je
>>>> passe toujours par l'h ritage. Un enum, c'est une classe
>>>> abstraite et il y a autant de sous-classes que de valeurs
>>>> dans l'enum.
>>> Faut pas faire dans le dogmatisme. Il faut utiliser les
>>> enums pour ce quoi elle sont utiles; effectivement, si
>>> c'est pour faire un m canisme de s lection de type, le
>>> polymorphisme est plus adapt . Mais dans ce cas, tu
>>> aurais en dire autant des switches.
>> La chasse aux switches est la programmation objet ce que la
>> chasse aux gotos est la programmation structurée.
> Pas tout fait : si c'est vrai qu'on en a beaucoup moins
> besoin des switches quand on a le polymorphisme, il y a
> encore des cas, par exemple, un switch sur un caract re lu
> sur l'interface utilisateur. (Une fois, juste pour voir,
> j'ai essay d'écrire un bout de code sans les switch. Ça ne
> tient pas la route quand on a affaire des entrées en
> provenance de l'exterieur. Ni, par exemple, pour des choses
> du genre code d'erreur.)
Pour les 2 cas que tu cites,je suis d'accord. Dans un
analyseur lexical par exemple, les switches sont inévitables
puisqu'on ne connait pas le type de la donnée d'entrée.
Pour les codes d'erreur, il est préférable d'utiliser les
mécanismes d'exception quand on peut
mais a peut-être pénalisant pour les performances dans le cas
où l'algorithme impose une programmation par exception comme
pour un mécanisme de gestion des entrées/sorties dans un noyau
de système d'exploitation.
>> Les enums conduisent in vitablement des switches, c'est
>> pour cela que je ne les utilise pas.
> Tiens, là, tu m'apprends quelques choses. Parce que j'ai bien
> des enum dans mon code, mais pas de switch sur l'enum. (À
> quelques exceptions près.)
Ca veut dire que tu ne les utilises pas comme des ensembles de
valeur traiter alors ?
>> On n'aura tester que le code qui correspond aux nouvelles
>> valeurs.
> Pas du tout. Jamais une modification sans faire passer le jeu
> complet des tests de regression.
Je ne suis pas d'accord. Il y a des cas où on peut se
dispenser de passer la totalit des tests de non régression en
toute sécurité.
Heureusement, dans un compilateur par exemple, qu'on ne va pas
passer tous les tests de non régression la moindre
modification du code...
> Tout fait. Et comme mal écrit , on entend aussi les cas où
> la technologie ne convenait pas.
Il y a effectivement des applications pour lesquelles l'objet
ne convient pas.
> [...]
> Par définition, n'est-ce pas ? C'est pour a qu'il faut bien
> dire que l'objet n'est pas un silver bullet ; qu'il ne convient
> pas pour tout. (Je fais pas mal de calcul numérique en ce
> moment ; heureusement que je ne suis pas obligé à me servir
> d'une classe polymorique pour les doubles.)
Ca dépend du contexte. J'ai connu une application qui faisait
des calculs de déformation de pièces en fonction de
contraintes tangentielles pour fabriquer des abaques
d'usinage. les polynômes manipulés pouvaient avoir des
coefficients de toute nature (rationnels, réels et même des
matrices). On a utilisé le polymorphisme pour les coefficients
et cela a rendu le code d'une simplicit biblique alors que le
problème était très complexe.
Je pense que c'est parce que, aujourd'hui, on utilise le C++
là où on devrait continuer utiliser C.
>> mais quand on est dans l'industrie, ça devient un problème
>> d'éthique : on ne fait pas joujou avec le code quand il s'agit
>> de logiciels pour l'avionique ou les centrales nucl aires. En
>> plus,il y a des m canismes de certification draconiens.
> Qui, la plupart du temps, interdisent le polymorphisme.
Et bien justement, pas toujours et on peut faire du code absolument sûr
en utilisant intensivement le polymorphisme
James Kanze a crit :
> On 27 Jan, 22:26, Wykaaa <wyk...@yahoo.fr> wrote:
>> Stan a écrit :
>>> On 27 jan, 20:45, Wykaaa <wyk...@yahoo.fr> wrote:
>>>> En approche objet, je n'utilise jamais des enums. Je
>>>> passe toujours par l'h ritage. Un enum, c'est une classe
>>>> abstraite et il y a autant de sous-classes que de valeurs
>>>> dans l'enum.
>>> Faut pas faire dans le dogmatisme. Il faut utiliser les
>>> enums pour ce quoi elle sont utiles; effectivement, si
>>> c'est pour faire un m canisme de s lection de type, le
>>> polymorphisme est plus adapt . Mais dans ce cas, tu
>>> aurais en dire autant des switches.
>> La chasse aux switches est la programmation objet ce que la
>> chasse aux gotos est la programmation structurée.
> Pas tout fait : si c'est vrai qu'on en a beaucoup moins
> besoin des switches quand on a le polymorphisme, il y a
> encore des cas, par exemple, un switch sur un caract re lu
> sur l'interface utilisateur. (Une fois, juste pour voir,
> j'ai essay d'écrire un bout de code sans les switch. Ça ne
> tient pas la route quand on a affaire des entrées en
> provenance de l'exterieur. Ni, par exemple, pour des choses
> du genre code d'erreur.)
Pour les 2 cas que tu cites,je suis d'accord. Dans un
analyseur lexical par exemple, les switches sont inévitables
puisqu'on ne connait pas le type de la donnée d'entrée.
Pour les codes d'erreur, il est préférable d'utiliser les
mécanismes d'exception quand on peut
mais a peut-être pénalisant pour les performances dans le cas
où l'algorithme impose une programmation par exception comme
pour un mécanisme de gestion des entrées/sorties dans un noyau
de système d'exploitation.
>> Les enums conduisent in vitablement des switches, c'est
>> pour cela que je ne les utilise pas.
> Tiens, là, tu m'apprends quelques choses. Parce que j'ai bien
> des enum dans mon code, mais pas de switch sur l'enum. (À
> quelques exceptions près.)
Ca veut dire que tu ne les utilises pas comme des ensembles de
valeur traiter alors ?
>> On n'aura tester que le code qui correspond aux nouvelles
>> valeurs.
> Pas du tout. Jamais une modification sans faire passer le jeu
> complet des tests de regression.
Je ne suis pas d'accord. Il y a des cas où on peut se
dispenser de passer la totalit des tests de non régression en
toute sécurité.
Heureusement, dans un compilateur par exemple, qu'on ne va pas
passer tous les tests de non régression la moindre
modification du code...
> Tout fait. Et comme mal écrit , on entend aussi les cas où
> la technologie ne convenait pas.
Il y a effectivement des applications pour lesquelles l'objet
ne convient pas.
> [...]
> Par définition, n'est-ce pas ? C'est pour a qu'il faut bien
> dire que l'objet n'est pas un silver bullet ; qu'il ne convient
> pas pour tout. (Je fais pas mal de calcul numérique en ce
> moment ; heureusement que je ne suis pas obligé à me servir
> d'une classe polymorique pour les doubles.)
Ca dépend du contexte. J'ai connu une application qui faisait
des calculs de déformation de pièces en fonction de
contraintes tangentielles pour fabriquer des abaques
d'usinage. les polynômes manipulés pouvaient avoir des
coefficients de toute nature (rationnels, réels et même des
matrices). On a utilisé le polymorphisme pour les coefficients
et cela a rendu le code d'une simplicit biblique alors que le
problème était très complexe.
Je pense que c'est parce que, aujourd'hui, on utilise le C++
là où on devrait continuer utiliser C.
>> mais quand on est dans l'industrie, ça devient un problème
>> d'éthique : on ne fait pas joujou avec le code quand il s'agit
>> de logiciels pour l'avionique ou les centrales nucl aires. En
>> plus,il y a des m canismes de certification draconiens.
> Qui, la plupart du temps, interdisent le polymorphisme.
Et bien justement, pas toujours et on peut faire du code absolument sûr
en utilisant intensivement le polymorphisme
James Kanze a crit :
> On 27 Jan, 22:26, Wykaaa wrote:
>> Stan a écrit :
>>> On 27 jan, 20:45, Wykaaa wrote:
>>>> En approche objet, je n'utilise jamais des enums. Je
>>>> passe toujours par l'h ritage. Un enum, c'est une classe
>>>> abstraite et il y a autant de sous-classes que de valeurs
>>>> dans l'enum.
>>> Faut pas faire dans le dogmatisme. Il faut utiliser les
>>> enums pour ce quoi elle sont utiles; effectivement, si
>>> c'est pour faire un m canisme de s lection de type, le
>>> polymorphisme est plus adapt . Mais dans ce cas, tu
>>> aurais en dire autant des switches.
>> La chasse aux switches est la programmation objet ce que la
>> chasse aux gotos est la programmation structurée.
> Pas tout fait : si c'est vrai qu'on en a beaucoup moins
> besoin des switches quand on a le polymorphisme, il y a
> encore des cas, par exemple, un switch sur un caract re lu
> sur l'interface utilisateur. (Une fois, juste pour voir,
> j'ai essay d'écrire un bout de code sans les switch. Ça ne
> tient pas la route quand on a affaire des entrées en
> provenance de l'exterieur. Ni, par exemple, pour des choses
> du genre code d'erreur.)
Pour les 2 cas que tu cites,je suis d'accord. Dans un
analyseur lexical par exemple, les switches sont inévitables
puisqu'on ne connait pas le type de la donnée d'entrée.
Pour les codes d'erreur, il est préférable d'utiliser les
mécanismes d'exception quand on peut
mais a peut-être pénalisant pour les performances dans le cas
où l'algorithme impose une programmation par exception comme
pour un mécanisme de gestion des entrées/sorties dans un noyau
de système d'exploitation.
>> Les enums conduisent in vitablement des switches, c'est
>> pour cela que je ne les utilise pas.
> Tiens, là, tu m'apprends quelques choses. Parce que j'ai bien
> des enum dans mon code, mais pas de switch sur l'enum. (À
> quelques exceptions près.)
Ca veut dire que tu ne les utilises pas comme des ensembles de
valeur traiter alors ?
>> On n'aura tester que le code qui correspond aux nouvelles
>> valeurs.
> Pas du tout. Jamais une modification sans faire passer le jeu
> complet des tests de regression.
Je ne suis pas d'accord. Il y a des cas où on peut se
dispenser de passer la totalit des tests de non régression en
toute sécurité.
Heureusement, dans un compilateur par exemple, qu'on ne va pas
passer tous les tests de non régression la moindre
modification du code...
> Tout fait. Et comme mal écrit , on entend aussi les cas où
> la technologie ne convenait pas.
Il y a effectivement des applications pour lesquelles l'objet
ne convient pas.
> [...]
> Par définition, n'est-ce pas ? C'est pour a qu'il faut bien
> dire que l'objet n'est pas un silver bullet ; qu'il ne convient
> pas pour tout. (Je fais pas mal de calcul numérique en ce
> moment ; heureusement que je ne suis pas obligé à me servir
> d'une classe polymorique pour les doubles.)
Ca dépend du contexte. J'ai connu une application qui faisait
des calculs de déformation de pièces en fonction de
contraintes tangentielles pour fabriquer des abaques
d'usinage. les polynômes manipulés pouvaient avoir des
coefficients de toute nature (rationnels, réels et même des
matrices). On a utilisé le polymorphisme pour les coefficients
et cela a rendu le code d'une simplicit biblique alors que le
problème était très complexe.
Je pense que c'est parce que, aujourd'hui, on utilise le C++
là où on devrait continuer utiliser C.
>> mais quand on est dans l'industrie, ça devient un problème
>> d'éthique : on ne fait pas joujou avec le code quand il s'agit
>> de logiciels pour l'avionique ou les centrales nucl aires. En
>> plus,il y a des m canismes de certification draconiens.
> Qui, la plupart du temps, interdisent le polymorphisme.
Et bien justement, pas toujours et on peut faire du code absolument sûr
en utilisant intensivement le polymorphisme
James Kanze a écrit :
> On 28 Jan, 11:53, Wykaaa wrote:
>> Stan a écrit :
>>> On 28 jan, 00:09, Wykaaa wrote:
>>> [...]
> Et comment. Il montre bien le problème de ne pas utiliser un
> enum. Utiliser des classes distinctes, comme tu as voulu faire,
> signifie que les fonctions qui déterminent le jour doivent
> connaître ton application.
Ah oui ? et pourquoi ?
Et même si cela était gênant, dans certain cas, j'utiliserais
le pattern Factory ou AbstractFactory.
> Il va radicalement à l'encontre de l'encapsulation. Tandis
> que l'enum...
Ben, il est pas encapsulé du tout...
> (Et en passant, est-ce que tu penses réelement qu'il faut
> que le code prenne en compte la possibilité que le nombre de
> jours dans la semaine change ? Il y a quand même des limites
> à la généricité.)
Mon exemple était là pour illustrer le principe. Il ne faut
pas le prendre "au pied de la lettre". Supposons qu'il
s'agisse d'instructions assembleur (au lieu des jours) et que
travailler() soit la fonction executer() et que le jeu
d'instructions évolue.
>> Les switches sont une horreur pour la maintenance et les
>> évolutions quand on fait de l'objet alors que le
>> polymorphisme rend les "aiguillages" automatiques quand on
>> ajoute des sous-classes.
> Le polymorphisme est une horreur pour la maintenance quand
> l'information décisive est calculée autre part que dans le
> code applicatif.
C'est juste une question de documentation d'interface.
James Kanze a écrit :
> On 28 Jan, 11:53, Wykaaa <wyk...@yahoo.fr> wrote:
>> Stan a écrit :
>>> On 28 jan, 00:09, Wykaaa <wyk...@yahoo.fr> wrote:
>>> [...]
> Et comment. Il montre bien le problème de ne pas utiliser un
> enum. Utiliser des classes distinctes, comme tu as voulu faire,
> signifie que les fonctions qui déterminent le jour doivent
> connaître ton application.
Ah oui ? et pourquoi ?
Et même si cela était gênant, dans certain cas, j'utiliserais
le pattern Factory ou AbstractFactory.
> Il va radicalement à l'encontre de l'encapsulation. Tandis
> que l'enum...
Ben, il est pas encapsulé du tout...
> (Et en passant, est-ce que tu penses réelement qu'il faut
> que le code prenne en compte la possibilité que le nombre de
> jours dans la semaine change ? Il y a quand même des limites
> à la généricité.)
Mon exemple était là pour illustrer le principe. Il ne faut
pas le prendre "au pied de la lettre". Supposons qu'il
s'agisse d'instructions assembleur (au lieu des jours) et que
travailler() soit la fonction executer() et que le jeu
d'instructions évolue.
>> Les switches sont une horreur pour la maintenance et les
>> évolutions quand on fait de l'objet alors que le
>> polymorphisme rend les "aiguillages" automatiques quand on
>> ajoute des sous-classes.
> Le polymorphisme est une horreur pour la maintenance quand
> l'information décisive est calculée autre part que dans le
> code applicatif.
C'est juste une question de documentation d'interface.
James Kanze a écrit :
> On 28 Jan, 11:53, Wykaaa wrote:
>> Stan a écrit :
>>> On 28 jan, 00:09, Wykaaa wrote:
>>> [...]
> Et comment. Il montre bien le problème de ne pas utiliser un
> enum. Utiliser des classes distinctes, comme tu as voulu faire,
> signifie que les fonctions qui déterminent le jour doivent
> connaître ton application.
Ah oui ? et pourquoi ?
Et même si cela était gênant, dans certain cas, j'utiliserais
le pattern Factory ou AbstractFactory.
> Il va radicalement à l'encontre de l'encapsulation. Tandis
> que l'enum...
Ben, il est pas encapsulé du tout...
> (Et en passant, est-ce que tu penses réelement qu'il faut
> que le code prenne en compte la possibilité que le nombre de
> jours dans la semaine change ? Il y a quand même des limites
> à la généricité.)
Mon exemple était là pour illustrer le principe. Il ne faut
pas le prendre "au pied de la lettre". Supposons qu'il
s'agisse d'instructions assembleur (au lieu des jours) et que
travailler() soit la fonction executer() et que le jeu
d'instructions évolue.
>> Les switches sont une horreur pour la maintenance et les
>> évolutions quand on fait de l'objet alors que le
>> polymorphisme rend les "aiguillages" automatiques quand on
>> ajoute des sous-classes.
> Le polymorphisme est une horreur pour la maintenance quand
> l'information décisive est calculée autre part que dans le
> code applicatif.
C'est juste une question de documentation d'interface.
On Jan 28, 8:39 pm, Wykaaa wrote:
Je ne suis pas d'accord. Il y a des cas où on peut se
dispenser de passer la totalit des tests de non régression en
toute sécurité.
Le système de build chez moi ne le permet pas. C'est impossible,
tel que j'ai écrit mes fichiers de make, d'exporter un en-tête
ou des fichiers objet sans que tous les tests passent.
C'est un des b a ba de la qualité.
Heureusement, dans un compilateur par exemple, qu'on ne va pas
passer tous les tests de non régression la moindre
modification du code...
Est-ce que ça ne serait-il pas l'explication des problèmes de
qualité dans certains compilateurs ?
[...]Tout fait. Et comme mal écrit , on entend aussi les cas où
la technologie ne convenait pas.Il y a effectivement des applications pour lesquelles l'objet
ne convient pas.
Voire même des parties de l'application où l'objet ne convient
pas. Qu'est-ce que l'objet apporte dans la représentation d'un
adresse IP, ou un montant monétaire ?
[...]
Par définition, n'est-ce pas ? C'est pour a qu'il faut bien
dire que l'objet n'est pas un silver bullet ; qu'il ne convient
pas pour tout. (Je fais pas mal de calcul numérique en ce
moment ; heureusement que je ne suis pas obligé à me servir
d'une classe polymorique pour les doubles.)Ca dépend du contexte. J'ai connu une application qui faisait
des calculs de déformation de pièces en fonction de
contraintes tangentielles pour fabriquer des abaques
d'usinage. les polynômes manipulés pouvaient avoir des
coefficients de toute nature (rationnels, réels et même des
matrices). On a utilisé le polymorphisme pour les coefficients
et cela a rendu le code d'une simplicit biblique alors que le
problème était très complexe.
Comme tu dis, ça dépend. Le désavantage des objets
polymorphiques, c'est qu'on ne peut pas facilement les copier ;
on se retrouve avec une sémantique de référence. Que ça convient
ou non.
[...]Je pense que c'est parce que, aujourd'hui, on utilise le C++
là où on devrait continuer utiliser C.
Il n'y a nul part où on devrait continuer à utiliser le C. Les
contrôles d'accès apporte déjà suffisamment de justifier le C++,
même si on ne se sert de rien d'autre en plus du C.
[...]mais quand on est dans l'industrie, ça devient un problème
d'éthique : on ne fait pas joujou avec le code quand il s'agit
de logiciels pour l'avionique ou les centrales nucl aires. En
plus,il y a des m canismes de certification draconiens.Qui, la plupart du temps, interdisent le polymorphisme.Et bien justement, pas toujours et on peut faire du code absolument sûr
en utilisant intensivement le polymorphisme
Mais c'est quand même plus difficile à prouver que le code
marche quand on ne sait pas quelle fonction sera appelée.
On Jan 28, 8:39 pm, Wykaaa <wyk...@yahoo.fr> wrote:
Je ne suis pas d'accord. Il y a des cas où on peut se
dispenser de passer la totalit des tests de non régression en
toute sécurité.
Le système de build chez moi ne le permet pas. C'est impossible,
tel que j'ai écrit mes fichiers de make, d'exporter un en-tête
ou des fichiers objet sans que tous les tests passent.
C'est un des b a ba de la qualité.
Heureusement, dans un compilateur par exemple, qu'on ne va pas
passer tous les tests de non régression la moindre
modification du code...
Est-ce que ça ne serait-il pas l'explication des problèmes de
qualité dans certains compilateurs ?
[...]
Tout fait. Et comme mal écrit , on entend aussi les cas où
la technologie ne convenait pas.
Il y a effectivement des applications pour lesquelles l'objet
ne convient pas.
Voire même des parties de l'application où l'objet ne convient
pas. Qu'est-ce que l'objet apporte dans la représentation d'un
adresse IP, ou un montant monétaire ?
[...]
Par définition, n'est-ce pas ? C'est pour a qu'il faut bien
dire que l'objet n'est pas un silver bullet ; qu'il ne convient
pas pour tout. (Je fais pas mal de calcul numérique en ce
moment ; heureusement que je ne suis pas obligé à me servir
d'une classe polymorique pour les doubles.)
Ca dépend du contexte. J'ai connu une application qui faisait
des calculs de déformation de pièces en fonction de
contraintes tangentielles pour fabriquer des abaques
d'usinage. les polynômes manipulés pouvaient avoir des
coefficients de toute nature (rationnels, réels et même des
matrices). On a utilisé le polymorphisme pour les coefficients
et cela a rendu le code d'une simplicit biblique alors que le
problème était très complexe.
Comme tu dis, ça dépend. Le désavantage des objets
polymorphiques, c'est qu'on ne peut pas facilement les copier ;
on se retrouve avec une sémantique de référence. Que ça convient
ou non.
[...]
Je pense que c'est parce que, aujourd'hui, on utilise le C++
là où on devrait continuer utiliser C.
Il n'y a nul part où on devrait continuer à utiliser le C. Les
contrôles d'accès apporte déjà suffisamment de justifier le C++,
même si on ne se sert de rien d'autre en plus du C.
[...]
mais quand on est dans l'industrie, ça devient un problème
d'éthique : on ne fait pas joujou avec le code quand il s'agit
de logiciels pour l'avionique ou les centrales nucl aires. En
plus,il y a des m canismes de certification draconiens.
Qui, la plupart du temps, interdisent le polymorphisme.
Et bien justement, pas toujours et on peut faire du code absolument sûr
en utilisant intensivement le polymorphisme
Mais c'est quand même plus difficile à prouver que le code
marche quand on ne sait pas quelle fonction sera appelée.
On Jan 28, 8:39 pm, Wykaaa wrote:
Je ne suis pas d'accord. Il y a des cas où on peut se
dispenser de passer la totalit des tests de non régression en
toute sécurité.
Le système de build chez moi ne le permet pas. C'est impossible,
tel que j'ai écrit mes fichiers de make, d'exporter un en-tête
ou des fichiers objet sans que tous les tests passent.
C'est un des b a ba de la qualité.
Heureusement, dans un compilateur par exemple, qu'on ne va pas
passer tous les tests de non régression la moindre
modification du code...
Est-ce que ça ne serait-il pas l'explication des problèmes de
qualité dans certains compilateurs ?
[...]Tout fait. Et comme mal écrit , on entend aussi les cas où
la technologie ne convenait pas.Il y a effectivement des applications pour lesquelles l'objet
ne convient pas.
Voire même des parties de l'application où l'objet ne convient
pas. Qu'est-ce que l'objet apporte dans la représentation d'un
adresse IP, ou un montant monétaire ?
[...]
Par définition, n'est-ce pas ? C'est pour a qu'il faut bien
dire que l'objet n'est pas un silver bullet ; qu'il ne convient
pas pour tout. (Je fais pas mal de calcul numérique en ce
moment ; heureusement que je ne suis pas obligé à me servir
d'une classe polymorique pour les doubles.)Ca dépend du contexte. J'ai connu une application qui faisait
des calculs de déformation de pièces en fonction de
contraintes tangentielles pour fabriquer des abaques
d'usinage. les polynômes manipulés pouvaient avoir des
coefficients de toute nature (rationnels, réels et même des
matrices). On a utilisé le polymorphisme pour les coefficients
et cela a rendu le code d'une simplicit biblique alors que le
problème était très complexe.
Comme tu dis, ça dépend. Le désavantage des objets
polymorphiques, c'est qu'on ne peut pas facilement les copier ;
on se retrouve avec une sémantique de référence. Que ça convient
ou non.
[...]Je pense que c'est parce que, aujourd'hui, on utilise le C++
là où on devrait continuer utiliser C.
Il n'y a nul part où on devrait continuer à utiliser le C. Les
contrôles d'accès apporte déjà suffisamment de justifier le C++,
même si on ne se sert de rien d'autre en plus du C.
[...]mais quand on est dans l'industrie, ça devient un problème
d'éthique : on ne fait pas joujou avec le code quand il s'agit
de logiciels pour l'avionique ou les centrales nucl aires. En
plus,il y a des m canismes de certification draconiens.Qui, la plupart du temps, interdisent le polymorphisme.Et bien justement, pas toujours et on peut faire du code absolument sûr
en utilisant intensivement le polymorphisme
Mais c'est quand même plus difficile à prouver que le code
marche quand on ne sait pas quelle fonction sera appelée.