In article ,
Michael Doubez wrote:Dans le cas de l'échequier je ne suis pas sûr que la modélisation des
pièces soit un point central. Une recherche se fera plutôt sur l'état
d'un plateau, les pièces existeront en instance unique pour générer
les états de plateau suivant.
Normalement, on commence par realiser une conception logiquement fiable, et
ensuite on se pose des questions eventuelles d'efficacite.
Sur ce type d'exemple, je pense directement au pattern flyweight, par exemple.
In article <0fb562a6-9444-46ac-b379-62c576a63b06@c4g2000yqa.googlegroups.com>,
Michael Doubez <michael.doubez@free.fr> wrote:
Dans le cas de l'échequier je ne suis pas sûr que la modélisation des
pièces soit un point central. Une recherche se fera plutôt sur l'état
d'un plateau, les pièces existeront en instance unique pour générer
les états de plateau suivant.
Normalement, on commence par realiser une conception logiquement fiable, et
ensuite on se pose des questions eventuelles d'efficacite.
Sur ce type d'exemple, je pense directement au pattern flyweight, par exemple.
In article ,
Michael Doubez wrote:Dans le cas de l'échequier je ne suis pas sûr que la modélisation des
pièces soit un point central. Une recherche se fera plutôt sur l'état
d'un plateau, les pièces existeront en instance unique pour générer
les états de plateau suivant.
Normalement, on commence par realiser une conception logiquement fiable, et
ensuite on se pose des questions eventuelles d'efficacite.
Sur ce type d'exemple, je pense directement au pattern flyweight, par exemple.
Ce n'est pas la question ici car tu n'en a pas forcément besoin, mais s i
tu veux passer par une AbstractFactory pour créer les jours, libre à toi
En approche objet, je n'utilise jamais des enums. Je passe toujours par
l'héritage.
et je te renvoie, dans ce cas, à la littérature abondante qui explici te
la chose...
Ce n'est pas la question ici car tu n'en a pas forcément besoin, mais s i
tu veux passer par une AbstractFactory pour créer les jours, libre à toi
En approche objet, je n'utilise jamais des enums. Je passe toujours par
l'héritage.
et je te renvoie, dans ce cas, à la littérature abondante qui explici te
la chose...
Ce n'est pas la question ici car tu n'en a pas forcément besoin, mais s i
tu veux passer par une AbstractFactory pour créer les jours, libre à toi
En approche objet, je n'utilise jamais des enums. Je passe toujours par
l'héritage.
et je te renvoie, dans ce cas, à la littérature abondante qui explici te
la chose...
Ce n'est pas la question ici car tu n'en a pas forcément besoin, mais s i
tu veux passer par une AbstractFactory pour créer les jours, libre à toi
et je te renvoie, dans ce cas, à la littérature abondante qui explici te
la chose...
En approche objet, je n'utilise jamais des enums. Je passe toujours par
l'héritage.
et je te renvoie, dans ce cas, à la littérature abondante qui explici te
la chose...
Ce n'est pas la question ici car tu n'en a pas forcément besoin, mais s i
tu veux passer par une AbstractFactory pour créer les jours, libre à toi
et je te renvoie, dans ce cas, à la littérature abondante qui explici te
la chose...
En approche objet, je n'utilise jamais des enums. Je passe toujours par
l'héritage.
et je te renvoie, dans ce cas, à la littérature abondante qui explici te
la chose...
Ce n'est pas la question ici car tu n'en a pas forcément besoin, mais s i
tu veux passer par une AbstractFactory pour créer les jours, libre à toi
et je te renvoie, dans ce cas, à la littérature abondante qui explici te
la chose...
En approche objet, je n'utilise jamais des enums. Je passe toujours par
l'héritage.
et je te renvoie, dans ce cas, à la littérature abondante qui explici te
la chose...
On 28 jan, 17:03, Wykaaa wrote:Ce n'est pas la question ici car tu n'en a pas forcément besoin, mais si
tu veux passer par une AbstractFactory pour créer les jours, libre à toi
et je te renvoie, dans ce cas, à la littérature abondante qui explicite
la chose...
La question a un rapport avec :En approche objet, je n'utilise jamais des enums. Je passe toujours par
l'héritage.
Or 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.
et je te renvoie, dans ce cas, à la littérature abondante qui explicite
la chose...
Je ne relève même pas :-|
On 28 jan, 17:03, Wykaaa <wyk...@yahoo.fr> wrote:
Ce n'est pas la question ici car tu n'en a pas forcément besoin, mais si
tu veux passer par une AbstractFactory pour créer les jours, libre à toi
et je te renvoie, dans ce cas, à la littérature abondante qui explicite
la chose...
La question a un rapport avec :
En approche objet, je n'utilise jamais des enums. Je passe toujours par
l'héritage.
Or 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.
et je te renvoie, dans ce cas, à la littérature abondante qui explicite
la chose...
Je ne relève même pas :-|
On 28 jan, 17:03, Wykaaa wrote:Ce n'est pas la question ici car tu n'en a pas forcément besoin, mais si
tu veux passer par une AbstractFactory pour créer les jours, libre à toi
et je te renvoie, dans ce cas, à la littérature abondante qui explicite
la chose...
La question a un rapport avec :En approche objet, je n'utilise jamais des enums. Je passe toujours par
l'héritage.
Or 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.
et je te renvoie, dans ce cas, à la littérature abondante qui explicite
la chose...
Je ne relève même pas :-|
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.
Les enums conduisent inévitablement à des switches, c'est pour
cela que je ne les utilise pas.
> J'ai vu beaucoup de projets où l'héritage était utilisé à
> outrance, où tout était modélisé en classes :
> ces programmes étaient difficiles à comprendre et à maintenir.
Ce qui est difficile à maintenir ce sont les switches
dépendant d'énums auxquels on va ajouter des valeurs (il va
falloir faire tous les tests de non régression) alors qu'avec
l'héritage on ajoutera les sous-classes correspondant aux
valeurs ajoutées *sans toucher au code existant*.
On n'aura à tester que le code qui correspond aux nouvelles
valeurs.
Où sont les difficultés de maintenance avec du code purement objet ?
Quant à la compréhension du code purement objet, il apparaît diffic ile
pour 2 raisons essentiellement :
1) Soit les gens qui le lisent ne sont pas suffisamment formés ou
habitués à l'objet
2) Soit le code est mal écrit (en fait c'est plutôt souvent parce que la
conception objet est mal foutue).
Enfin, pour finir et enfoncer le clou, dans une approche
objet, tout, absolument tout, doit être modélisé en classes et
le polymorphisme doit être utilisé à tous les niveaux des
hiérarchies de classes.
Faire autrement, dans des langages objets comme C++ ou Java,
c'est vouloir utiliser ces langages pour autre chose que ce
pourquoi ils ont été inventés.
Maintenant on peut aimer jouer à se faire peur en n'écoutant
pas les leçons de l'histoire de l'informatique
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.
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.
Les enums conduisent inévitablement à des switches, c'est pour
cela que je ne les utilise pas.
> J'ai vu beaucoup de projets où l'héritage était utilisé à
> outrance, où tout était modélisé en classes :
> ces programmes étaient difficiles à comprendre et à maintenir.
Ce qui est difficile à maintenir ce sont les switches
dépendant d'énums auxquels on va ajouter des valeurs (il va
falloir faire tous les tests de non régression) alors qu'avec
l'héritage on ajoutera les sous-classes correspondant aux
valeurs ajoutées *sans toucher au code existant*.
On n'aura à tester que le code qui correspond aux nouvelles
valeurs.
Où sont les difficultés de maintenance avec du code purement objet ?
Quant à la compréhension du code purement objet, il apparaît diffic ile
pour 2 raisons essentiellement :
1) Soit les gens qui le lisent ne sont pas suffisamment formés ou
habitués à l'objet
2) Soit le code est mal écrit (en fait c'est plutôt souvent parce que la
conception objet est mal foutue).
Enfin, pour finir et enfoncer le clou, dans une approche
objet, tout, absolument tout, doit être modélisé en classes et
le polymorphisme doit être utilisé à tous les niveaux des
hiérarchies de classes.
Faire autrement, dans des langages objets comme C++ ou Java,
c'est vouloir utiliser ces langages pour autre chose que ce
pourquoi ils ont été inventés.
Maintenant on peut aimer jouer à se faire peur en n'écoutant
pas les leçons de l'histoire de l'informatique
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.
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.
Les enums conduisent inévitablement à des switches, c'est pour
cela que je ne les utilise pas.
> J'ai vu beaucoup de projets où l'héritage était utilisé à
> outrance, où tout était modélisé en classes :
> ces programmes étaient difficiles à comprendre et à maintenir.
Ce qui est difficile à maintenir ce sont les switches
dépendant d'énums auxquels on va ajouter des valeurs (il va
falloir faire tous les tests de non régression) alors qu'avec
l'héritage on ajoutera les sous-classes correspondant aux
valeurs ajoutées *sans toucher au code existant*.
On n'aura à tester que le code qui correspond aux nouvelles
valeurs.
Où sont les difficultés de maintenance avec du code purement objet ?
Quant à la compréhension du code purement objet, il apparaît diffic ile
pour 2 raisons essentiellement :
1) Soit les gens qui le lisent ne sont pas suffisamment formés ou
habitués à l'objet
2) Soit le code est mal écrit (en fait c'est plutôt souvent parce que la
conception objet est mal foutue).
Enfin, pour finir et enfoncer le clou, dans une approche
objet, tout, absolument tout, doit être modélisé en classes et
le polymorphisme doit être utilisé à tous les niveaux des
hiérarchies de classes.
Faire autrement, dans des langages objets comme C++ ou Java,
c'est vouloir utiliser ces langages pour autre chose que ce
pourquoi ils ont été inventés.
Maintenant on peut aimer jouer à se faire peur en n'écoutant
pas les leçons de l'histoire de l'informatique
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.
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.
>> 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"?
Et un enum, ça a un comportement puisqu'on le gère avec des
switches...
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 ?
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.
>> 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"?
Et un enum, ça a un comportement puisqu'on le gère avec des
switches...
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 ?
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.
>> 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"?
Et un enum, ça a un comportement puisqu'on le gère avec des
switches...
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 ?
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 ?
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.
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 ?
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.
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 ?
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.
(Certains de nos jours prétendent même que l'héritage en C++,
c'est du passée, et qu'il ne faut plus s'en servir.)
(Certains de nos jours prétendent même que l'héritage en C++,
c'est du passée, et qu'il ne faut plus s'en servir.)
(Certains de nos jours prétendent même que l'héritage en C++,
c'est du passée, et qu'il ne faut plus s'en servir.)
On 28 jan, 00: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.
Formellement, un enum est un type distinct constitué d'un
ensemble de constantes.
C'est l'utilisation que tu en fais qui a un but similaire.
> Tu veux dire qu'un enum est une variable scalaire quand tu
> dis "valeur"?
Qui a la propriété interressant qu'à la déclaration, la valeur d' un
enum est la valeur de l'enum précédent + 1.
> C'est pareil pour les pièces de l'échiquier et Move devient une m éthode
> virtuelle de Pièce.
> La promotion c'est la destruction de la pièce, objet de la promotion, et
> la création, avec la même position (que je préfère à l'identi fiant
> "coordonnées") de la pièce qui la remplace.
> Position est d'ailleurs elle-même une classe.
Dans le cas de l'échequier je ne suis pas sûr que la modélisation d es
pièces soit un point central. Une recherche se fera plutôt sur l'ét at
d'un plateau, les pièces existeront en instance unique pour générer
les états de plateau suivant.
On 28 jan, 00: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.
Formellement, un enum est un type distinct constitué d'un
ensemble de constantes.
C'est l'utilisation que tu en fais qui a un but similaire.
> Tu veux dire qu'un enum est une variable scalaire quand tu
> dis "valeur"?
Qui a la propriété interressant qu'à la déclaration, la valeur d' un
enum est la valeur de l'enum précédent + 1.
> C'est pareil pour les pièces de l'échiquier et Move devient une m éthode
> virtuelle de Pièce.
> La promotion c'est la destruction de la pièce, objet de la promotion, et
> la création, avec la même position (que je préfère à l'identi fiant
> "coordonnées") de la pièce qui la remplace.
> Position est d'ailleurs elle-même une classe.
Dans le cas de l'échequier je ne suis pas sûr que la modélisation d es
pièces soit un point central. Une recherche se fera plutôt sur l'ét at
d'un plateau, les pièces existeront en instance unique pour générer
les états de plateau suivant.
On 28 jan, 00: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.
Formellement, un enum est un type distinct constitué d'un
ensemble de constantes.
C'est l'utilisation que tu en fais qui a un but similaire.
> Tu veux dire qu'un enum est une variable scalaire quand tu
> dis "valeur"?
Qui a la propriété interressant qu'à la déclaration, la valeur d' un
enum est la valeur de l'enum précédent + 1.
> C'est pareil pour les pièces de l'échiquier et Move devient une m éthode
> virtuelle de Pièce.
> La promotion c'est la destruction de la pièce, objet de la promotion, et
> la création, avec la même position (que je préfère à l'identi fiant
> "coordonnées") de la pièce qui la remplace.
> Position est d'ailleurs elle-même une classe.
Dans le cas de l'échequier je ne suis pas sûr que la modélisation d es
pièces soit un point central. Une recherche se fera plutôt sur l'ét at
d'un plateau, les pièces existeront en instance unique pour générer
les états de plateau suivant.
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.)
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.)
J'ai vu beaucoup de projets où l'héritage était utilisé à
outrance, où tout était modélisé en classes :
ces programmes étaient difficiles à comprendre et à maintenir.Ce qui est difficile à maintenir ce sont les switches
dépendant d'énums auxquels on va ajouter des valeurs (il va
falloir faire tous les tests de non régression) alors qu'avec
l'héritage on ajoutera les sous-classes correspondant aux
valeurs ajoutées *sans toucher au code existant*.
Et alors. Il y a certainement des utilisations néfastes des
enums. Mais on peut faire du difficile à maintenir avec
n'importe quoi -- comme disait l'autre, il y a aussi des cas où
le polymorphisme rend le programme plus difficile à comprendre.
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.
Où sont les difficultés de maintenance avec du code purement objet ?
Quant à la compréhension du code purement objet, il apparaît difficile
pour 2 raisons essentiellement :
1) Soit les gens qui le lisent ne sont pas suffisamment formés ou
habitués à l'objet
2) Soit le code est mal écrit (en fait c'est plutôt souvent parce que la
conception objet est mal foutue).
Tout à fait. Et comme « mal écrit », on entend aussi les cas où
la technologie ne convenait pas.
À cet égard, l'objet n'est pas différent que n'importe quoi
d'autre (y compris les enum). Bien utilisé, à bonne échéance, il
facilite le travail. Mal utilisé, c'est tout à fait le
contraire.
[...]Enfin, pour finir et enfoncer le clou, dans une approche
objet, tout, absolument tout, doit être modélisé en classes et
le polymorphisme doit être utilisé à tous les niveaux des
hiérarchies de classes.
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.)
Faire autrement, dans des langages objets comme C++ ou Java,
c'est vouloir utiliser ces langages pour autre chose que ce
pourquoi ils ont été inventés.
C'est un peu le problème de Java, je te l'accorde. Mais C++ a
été inventé pour supporter de multiples paradigmes. Y essayer de
forcer tout à être un objet, c'est ne pas avoir compris le
langage, et ne pas l'utiliser comme son concepteur voulait.
(Certains de nos jours prétendent même que l'héritage en C++,
c'est du passée, et qu'il ne faut plus s'en servir.)
Maintenant on peut aimer jouer à se faire peur en n'écoutant
pas les leçons de l'histoire de l'informatique
La première leçon de l'histoire de l'informatique, c'est qu'il
n'y a pas de technologie miracle -- pas de silver bullet, comme
on dit en américain. Insister qu'une solution apporte la réponse
à tout problème, c'est de ne pas prêter attention aux leçons de
l'histoire.
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.
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.)
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.)
J'ai vu beaucoup de projets où l'héritage était utilisé à
outrance, où tout était modélisé en classes :
ces programmes étaient difficiles à comprendre et à maintenir.
Ce qui est difficile à maintenir ce sont les switches
dépendant d'énums auxquels on va ajouter des valeurs (il va
falloir faire tous les tests de non régression) alors qu'avec
l'héritage on ajoutera les sous-classes correspondant aux
valeurs ajoutées *sans toucher au code existant*.
Et alors. Il y a certainement des utilisations néfastes des
enums. Mais on peut faire du difficile à maintenir avec
n'importe quoi -- comme disait l'autre, il y a aussi des cas où
le polymorphisme rend le programme plus difficile à comprendre.
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.
Où sont les difficultés de maintenance avec du code purement objet ?
Quant à la compréhension du code purement objet, il apparaît difficile
pour 2 raisons essentiellement :
1) Soit les gens qui le lisent ne sont pas suffisamment formés ou
habitués à l'objet
2) Soit le code est mal écrit (en fait c'est plutôt souvent parce que la
conception objet est mal foutue).
Tout à fait. Et comme « mal écrit », on entend aussi les cas où
la technologie ne convenait pas.
À cet égard, l'objet n'est pas différent que n'importe quoi
d'autre (y compris les enum). Bien utilisé, à bonne échéance, il
facilite le travail. Mal utilisé, c'est tout à fait le
contraire.
[...]
Enfin, pour finir et enfoncer le clou, dans une approche
objet, tout, absolument tout, doit être modélisé en classes et
le polymorphisme doit être utilisé à tous les niveaux des
hiérarchies de classes.
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.)
Faire autrement, dans des langages objets comme C++ ou Java,
c'est vouloir utiliser ces langages pour autre chose que ce
pourquoi ils ont été inventés.
C'est un peu le problème de Java, je te l'accorde. Mais C++ a
été inventé pour supporter de multiples paradigmes. Y essayer de
forcer tout à être un objet, c'est ne pas avoir compris le
langage, et ne pas l'utiliser comme son concepteur voulait.
(Certains de nos jours prétendent même que l'héritage en C++,
c'est du passée, et qu'il ne faut plus s'en servir.)
Maintenant on peut aimer jouer à se faire peur en n'écoutant
pas les leçons de l'histoire de l'informatique
La première leçon de l'histoire de l'informatique, c'est qu'il
n'y a pas de technologie miracle -- pas de silver bullet, comme
on dit en américain. Insister qu'une solution apporte la réponse
à tout problème, c'est de ne pas prêter attention aux leçons de
l'histoire.
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.
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.)
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.)
J'ai vu beaucoup de projets où l'héritage était utilisé à
outrance, où tout était modélisé en classes :
ces programmes étaient difficiles à comprendre et à maintenir.Ce qui est difficile à maintenir ce sont les switches
dépendant d'énums auxquels on va ajouter des valeurs (il va
falloir faire tous les tests de non régression) alors qu'avec
l'héritage on ajoutera les sous-classes correspondant aux
valeurs ajoutées *sans toucher au code existant*.
Et alors. Il y a certainement des utilisations néfastes des
enums. Mais on peut faire du difficile à maintenir avec
n'importe quoi -- comme disait l'autre, il y a aussi des cas où
le polymorphisme rend le programme plus difficile à comprendre.
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.
Où sont les difficultés de maintenance avec du code purement objet ?
Quant à la compréhension du code purement objet, il apparaît difficile
pour 2 raisons essentiellement :
1) Soit les gens qui le lisent ne sont pas suffisamment formés ou
habitués à l'objet
2) Soit le code est mal écrit (en fait c'est plutôt souvent parce que la
conception objet est mal foutue).
Tout à fait. Et comme « mal écrit », on entend aussi les cas où
la technologie ne convenait pas.
À cet égard, l'objet n'est pas différent que n'importe quoi
d'autre (y compris les enum). Bien utilisé, à bonne échéance, il
facilite le travail. Mal utilisé, c'est tout à fait le
contraire.
[...]Enfin, pour finir et enfoncer le clou, dans une approche
objet, tout, absolument tout, doit être modélisé en classes et
le polymorphisme doit être utilisé à tous les niveaux des
hiérarchies de classes.
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.)
Faire autrement, dans des langages objets comme C++ ou Java,
c'est vouloir utiliser ces langages pour autre chose que ce
pourquoi ils ont été inventés.
C'est un peu le problème de Java, je te l'accorde. Mais C++ a
été inventé pour supporter de multiples paradigmes. Y essayer de
forcer tout à être un objet, c'est ne pas avoir compris le
langage, et ne pas l'utiliser comme son concepteur voulait.
(Certains de nos jours prétendent même que l'héritage en C++,
c'est du passée, et qu'il ne faut plus s'en servir.)
Maintenant on peut aimer jouer à se faire peur en n'écoutant
pas les leçons de l'histoire de l'informatique
La première leçon de l'histoire de l'informatique, c'est qu'il
n'y a pas de technologie miracle -- pas de silver bullet, comme
on dit en américain. Insister qu'une solution apporte la réponse
à tout problème, c'est de ne pas prêter attention aux leçons de
l'histoire.
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.