j'ai plusieurs threads qui tournent. chaque thread est un objet. dans
le programme principal, j'ai une liste de tous ces threads (dans un
tableau par exemple).
supposons qu'un thread se termine. comment peut-il prevenir le
programme principal, afin qu'il enleve sa reference de la liste de
threads ?
solution 1 (mauvaise) : le thread a une reference vers la liste, et il
peut la modifier. or, cela est absurde en programmation objet; le
thread (qui est un objet) n'a pas a contenir une reference vers la
liste.
solution 2 (mauvaise) : la liste est une variable globale. le thread
peut donc y avoir acces. or, une fois de plus, cela est absurde en
programmation objet; le thread n'a pas a s'occuper de mettre la liste
de threads a jour. il n'est meme pas cense savoir qu'il est repertorie
dans une liste.
existe-t-il une solution propre et non-marginale a ce probleme de
conception objet ?
il est beau ton chapeau. dans tous les programmes c++ un peu conséquents, on retrouve le pattern observer.
http://www.dofactory.com/Patterns/PatternObserver.aspx Frequency of use: high
En même temps, citer un site qui parle de C#, ASP.NET, VB.NET, XML, SOAP pour étayer une affirmation sur le C++ n'est pas très convainquant ;-)
mes excuses :)
-- js
Christophe Lephay
"luc2" a écrit dans le message de news:
je n'ai jamais dit qu'il devait etre automone, ni qu'il ne devait pas communiquer. ca depend comment on comprend "coherent par lui-meme". si on tient compte du contexte, "coherent par lui-meme" signifie qu'il ne doit pas contenir une liste de lui-meme. c'est ainsi que j'ai pris l'expression. apparemment, ce n'est pas ce que tu voulais dire. il y a donc une bonne probabilite pour que tu sois hors-contexte.
C'est pourquoi j'avais mis cohérent entre guillemets, car la notion de cohérence est très flou dans le cas dont on discute. Concernant la liste qui serait interne à l'objet, elle n'est pas nécessaire si tu passes par des listeners, mais elle le devient *par définition* si tu refuses d'utiliser des listeners sous le pretexte (fallacieux) qu'un listener ne serait pas idiomatique en C++.
Je dis "par définition" car c'est à celà que sert un listener, gerer la liste des objets à observer. Si tu ne veux pas centraliser cette gestion, tu n'as d'autres choix que de la gérer dans les objets eux-mêmes.
et parmi ces choix, y a-t-il une BONNE solution quelque part ? (c'est-a-dire, une solution qui repondrait a l'enonce ?)
Le même modèle que celui utilisé en Java est a priori une bonne solution. Cependant il faut envisager le cas que l'api ne te laisserait pas trop de choix, par exemple il se peut que l'api ne te permette pas d'intercepter les messages d'un thread par un autre processus, auquel cas ce serait de la responsabilité de l'objet thread que d'informer le listener de son état. *LA* bonne solution ne dépend pas que du langage et du design qu'on souhaite, mais aussi, possiblement, de l'environnement global du programme (les bibliothèques tierces ou l'api du système).
La finalité n'est pas la POO mais quelque chose d'autre que la POO elle-même tete d'atteindre. Le sage montre la lune et le fou regarde le doigt, comme dirait l'autre. La POO n'est pas une fin mais un moyen.
l'enonce l'exige. si tu ne veux pas repondre a l'enonce, rien ne t'y oblige.
En ignorant la finalité de la POO, tu peux difficilement dire que telle ou telle solution est ou n'est pas POO à moins que tu ne te bases que sur une position dogmatique.
La notion d'encapsulation, en particulier, n'indique pas qu'il faille tout encapsuler, mais qu'il convient de le faire *dans la mesure du possible*. Là, on quitte le monde du dogme religieux ou idéologique. Ce qu'on peut encapsuler ou non correspond à d'autres contraintes que celles du langage seul, à savoir l'environnement de l'application d'une manière plus générale.
"luc2" <luc2@nospam.invalid> a écrit dans le message de news:
g4u7u096hl5kk9qfuvl4aosglrld5bj2e1@4ax.com...
je n'ai jamais dit qu'il devait etre automone, ni qu'il ne devait pas
communiquer. ca depend comment on comprend "coherent par lui-meme". si
on tient compte du contexte, "coherent par lui-meme" signifie qu'il ne
doit pas contenir une liste de lui-meme. c'est ainsi que j'ai pris
l'expression. apparemment, ce n'est pas ce que tu voulais dire. il y a
donc une bonne probabilite pour que tu sois hors-contexte.
C'est pourquoi j'avais mis cohérent entre guillemets, car la notion de
cohérence est très flou dans le cas dont on discute. Concernant la liste qui
serait interne à l'objet, elle n'est pas nécessaire si tu passes par des
listeners, mais elle le devient *par définition* si tu refuses d'utiliser
des listeners sous le pretexte (fallacieux) qu'un listener ne serait pas
idiomatique en C++.
Je dis "par définition" car c'est à celà que sert un listener, gerer la
liste des objets à observer. Si tu ne veux pas centraliser cette gestion, tu
n'as d'autres choix que de la gérer dans les objets eux-mêmes.
et parmi ces choix, y a-t-il une BONNE solution quelque part ?
(c'est-a-dire, une solution qui repondrait a l'enonce ?)
Le même modèle que celui utilisé en Java est a priori une bonne solution.
Cependant il faut envisager le cas que l'api ne te laisserait pas trop de
choix, par exemple il se peut que l'api ne te permette pas d'intercepter les
messages d'un thread par un autre processus, auquel cas ce serait de la
responsabilité de l'objet thread que d'informer le listener de son état.
*LA* bonne solution ne dépend pas que du langage et du design qu'on
souhaite, mais aussi, possiblement, de l'environnement global du programme
(les bibliothèques tierces ou l'api du système).
La finalité n'est pas la
POO mais quelque chose d'autre que la POO elle-même tete d'atteindre. Le
sage montre la lune et le fou regarde le doigt, comme dirait l'autre. La
POO
n'est pas une fin mais un moyen.
l'enonce l'exige. si tu ne veux pas repondre a l'enonce, rien ne t'y
oblige.
En ignorant la finalité de la POO, tu peux difficilement dire que telle ou
telle solution est ou n'est pas POO à moins que tu ne te bases que sur une
position dogmatique.
La notion d'encapsulation, en particulier, n'indique pas qu'il faille tout
encapsuler, mais qu'il convient de le faire *dans la mesure du possible*.
Là, on quitte le monde du dogme religieux ou idéologique. Ce qu'on peut
encapsuler ou non correspond à d'autres contraintes que celles du langage
seul, à savoir l'environnement de l'application d'une manière plus générale.
je n'ai jamais dit qu'il devait etre automone, ni qu'il ne devait pas communiquer. ca depend comment on comprend "coherent par lui-meme". si on tient compte du contexte, "coherent par lui-meme" signifie qu'il ne doit pas contenir une liste de lui-meme. c'est ainsi que j'ai pris l'expression. apparemment, ce n'est pas ce que tu voulais dire. il y a donc une bonne probabilite pour que tu sois hors-contexte.
C'est pourquoi j'avais mis cohérent entre guillemets, car la notion de cohérence est très flou dans le cas dont on discute. Concernant la liste qui serait interne à l'objet, elle n'est pas nécessaire si tu passes par des listeners, mais elle le devient *par définition* si tu refuses d'utiliser des listeners sous le pretexte (fallacieux) qu'un listener ne serait pas idiomatique en C++.
Je dis "par définition" car c'est à celà que sert un listener, gerer la liste des objets à observer. Si tu ne veux pas centraliser cette gestion, tu n'as d'autres choix que de la gérer dans les objets eux-mêmes.
et parmi ces choix, y a-t-il une BONNE solution quelque part ? (c'est-a-dire, une solution qui repondrait a l'enonce ?)
Le même modèle que celui utilisé en Java est a priori une bonne solution. Cependant il faut envisager le cas que l'api ne te laisserait pas trop de choix, par exemple il se peut que l'api ne te permette pas d'intercepter les messages d'un thread par un autre processus, auquel cas ce serait de la responsabilité de l'objet thread que d'informer le listener de son état. *LA* bonne solution ne dépend pas que du langage et du design qu'on souhaite, mais aussi, possiblement, de l'environnement global du programme (les bibliothèques tierces ou l'api du système).
La finalité n'est pas la POO mais quelque chose d'autre que la POO elle-même tete d'atteindre. Le sage montre la lune et le fou regarde le doigt, comme dirait l'autre. La POO n'est pas une fin mais un moyen.
l'enonce l'exige. si tu ne veux pas repondre a l'enonce, rien ne t'y oblige.
En ignorant la finalité de la POO, tu peux difficilement dire que telle ou telle solution est ou n'est pas POO à moins que tu ne te bases que sur une position dogmatique.
La notion d'encapsulation, en particulier, n'indique pas qu'il faille tout encapsuler, mais qu'il convient de le faire *dans la mesure du possible*. Là, on quitte le monde du dogme religieux ou idéologique. Ce qu'on peut encapsuler ou non correspond à d'autres contraintes que celles du langage seul, à savoir l'environnement de l'application d'une manière plus générale.
luc2
On Tue, 11 Jan 2005 16:10:56 +0100, "Christophe Lephay" wrote:
Ah? La conception est toujours une affaire de compromis entre differents objectifs contradictoires, dont la simplicite et la generalite. Si tous les objets d'une classe doivent etre reference par un autre objet, le plus simple est de les faire s'inscrire dans les constructeurs et desinscrire dans le destructeur.
non. si c'est le constructeur de l'objet qui inscrit l'objet dans la liste, alors cela signifie que l'objet SAIT qu'il est dans une liste. or, il ne doit pas le savoir.
La résolution des problèmes s'accomode souvent assez mal avec les dogmes religieux.
la resolution de probleme doit repondre a l'enonce. si l'enonce demande une solution religieuse, on est oblige de s'y plier.
C'est rare qu'il y ait des solutions uniques a un probleme, il y a souvent plusieurs solutions qui offrent des compromis differents.
mais il DOIT TOUJOURS y avoir une solution qui respecte les principes de la programmation objet.
Même remarque.
meme replique.
Cela reste a mon avis a prouver mais en admettant cela en quoi est-ce un probleme? La conception OO est un outil, pas une religion. Quand un outil n'est pas celui qu'il me faut, j'en prend un autre.
dans l'enonce de mon probleme, il faut faire une conception orientee objet. si tu prends un autre outil, alors tu ne reponds pas au probleme.
Tu dis vouloir une conception orientée objet, mais tu sembles avoir une conception de la conception orientée objet qui t'est propre.
vraiment ? ca vous semble coherent a vous qu'un objet contienne une liste de lui-meme ? un bouton doit forcement contenir une liste de boutons ? une fenetre doit forcement contenir une liste de fenetres ? un thread doit forcement contenir une liste de threads ?
moi je pense que vous voyez TRES BIEN que ce n'est pas coherent, et que ma vision de la conception objet n'a rien de personnel.
Tu n'arretes pas de parler de principes de la programmation objet comme des dogmes. Peut-être serait-il temps de définir plus clairement quels seraient ces principes ?
vous en avez deja suffisamment pour raisonner : un objet faisant partie d'une liste n'a pas a contenir la liste elle-meme.
On Tue, 11 Jan 2005 16:10:56 +0100, "Christophe Lephay"
<christophe-lephay@wanadoo.fr> wrote:
Ah? La conception est toujours une affaire de compromis entre
differents objectifs contradictoires, dont la simplicite et la
generalite. Si tous les objets d'une classe doivent etre reference
par un autre objet, le plus simple est de les faire s'inscrire dans
les constructeurs et desinscrire dans le destructeur.
non. si c'est le constructeur de l'objet qui inscrit l'objet dans la
liste, alors cela signifie que l'objet SAIT qu'il est dans une liste.
or, il ne doit pas le savoir.
La résolution des problèmes s'accomode souvent assez mal avec les dogmes
religieux.
la resolution de probleme doit repondre a l'enonce. si l'enonce
demande une solution religieuse, on est oblige de s'y plier.
C'est rare qu'il y ait des
solutions uniques a un probleme, il y a souvent plusieurs solutions
qui offrent des compromis differents.
mais il DOIT TOUJOURS y avoir une solution qui respecte les principes
de la programmation objet.
Même remarque.
meme replique.
Cela reste a mon avis a prouver mais en admettant cela en quoi est-ce
un probleme? La conception OO est un outil, pas une religion. Quand
un outil n'est pas celui qu'il me faut, j'en prend un autre.
dans l'enonce de mon probleme, il faut faire une conception orientee
objet. si tu prends un autre outil, alors tu ne reponds pas au
probleme.
Tu dis vouloir une conception orientée objet, mais tu sembles avoir une
conception de la conception orientée objet qui t'est propre.
vraiment ? ca vous semble coherent a vous qu'un objet contienne une
liste de lui-meme ? un bouton doit forcement contenir une liste de
boutons ? une fenetre doit forcement contenir une liste de fenetres ?
un thread doit forcement contenir une liste de threads ?
moi je pense que vous voyez TRES BIEN que ce n'est pas coherent, et
que ma vision de la conception objet n'a rien de personnel.
Tu n'arretes pas de parler de principes de la programmation objet comme des
dogmes. Peut-être serait-il temps de définir plus clairement quels seraient
ces principes ?
vous en avez deja suffisamment pour raisonner : un objet faisant
partie d'une liste n'a pas a contenir la liste elle-meme.
On Tue, 11 Jan 2005 16:10:56 +0100, "Christophe Lephay" wrote:
Ah? La conception est toujours une affaire de compromis entre differents objectifs contradictoires, dont la simplicite et la generalite. Si tous les objets d'une classe doivent etre reference par un autre objet, le plus simple est de les faire s'inscrire dans les constructeurs et desinscrire dans le destructeur.
non. si c'est le constructeur de l'objet qui inscrit l'objet dans la liste, alors cela signifie que l'objet SAIT qu'il est dans une liste. or, il ne doit pas le savoir.
La résolution des problèmes s'accomode souvent assez mal avec les dogmes religieux.
la resolution de probleme doit repondre a l'enonce. si l'enonce demande une solution religieuse, on est oblige de s'y plier.
C'est rare qu'il y ait des solutions uniques a un probleme, il y a souvent plusieurs solutions qui offrent des compromis differents.
mais il DOIT TOUJOURS y avoir une solution qui respecte les principes de la programmation objet.
Même remarque.
meme replique.
Cela reste a mon avis a prouver mais en admettant cela en quoi est-ce un probleme? La conception OO est un outil, pas une religion. Quand un outil n'est pas celui qu'il me faut, j'en prend un autre.
dans l'enonce de mon probleme, il faut faire une conception orientee objet. si tu prends un autre outil, alors tu ne reponds pas au probleme.
Tu dis vouloir une conception orientée objet, mais tu sembles avoir une conception de la conception orientée objet qui t'est propre.
vraiment ? ca vous semble coherent a vous qu'un objet contienne une liste de lui-meme ? un bouton doit forcement contenir une liste de boutons ? une fenetre doit forcement contenir une liste de fenetres ? un thread doit forcement contenir une liste de threads ?
moi je pense que vous voyez TRES BIEN que ce n'est pas coherent, et que ma vision de la conception objet n'a rien de personnel.
Tu n'arretes pas de parler de principes de la programmation objet comme des dogmes. Peut-être serait-il temps de définir plus clairement quels seraient ces principes ?
vous en avez deja suffisamment pour raisonner : un objet faisant partie d'une liste n'a pas a contenir la liste elle-meme.
Christophe Lephay
"luc2" a écrit dans le message de news:
On Tue, 11 Jan 2005 16:10:56 +0100, "Christophe Lephay" vraiment ? ca vous semble coherent a vous qu'un objet contienne une liste de lui-meme ? un bouton doit forcement contenir une liste de boutons ? une fenetre doit forcement contenir une liste de fenetres ? un thread doit forcement contenir une liste de threads ?
Ce qui n'est pas coherent, c'est de refuser d'utiliser le pattern observer sous pretexte qu'il est utilisé en Java.
"luc2" <luc2@nospam.invalid> a écrit dans le message de news:
phv7u05eag0e2tmu42ob9a6411g5n2r25o@4ax.com...
On Tue, 11 Jan 2005 16:10:56 +0100, "Christophe Lephay"
vraiment ? ca vous semble coherent a vous qu'un objet contienne une
liste de lui-meme ? un bouton doit forcement contenir une liste de
boutons ? une fenetre doit forcement contenir une liste de fenetres ?
un thread doit forcement contenir une liste de threads ?
Ce qui n'est pas coherent, c'est de refuser d'utiliser le pattern observer
sous pretexte qu'il est utilisé en Java.
On Tue, 11 Jan 2005 16:10:56 +0100, "Christophe Lephay" vraiment ? ca vous semble coherent a vous qu'un objet contienne une liste de lui-meme ? un bouton doit forcement contenir une liste de boutons ? une fenetre doit forcement contenir une liste de fenetres ? un thread doit forcement contenir une liste de threads ?
Ce qui n'est pas coherent, c'est de refuser d'utiliser le pattern observer sous pretexte qu'il est utilisé en Java.
Christophe Lephay
"luc2" a écrit dans le message de news:
On Tue, 11 Jan 2005 16:12:22 +0100, "Christophe Lephay" wrote:
cette solution est equivalente a celle des listeners en java. or, ce n'est pas quelque chose de courant en c++.
Soit une solution convient, soit elle ne convient pas. si elle convient, peu importe qu'elle soit courante ou non. Si elle ne convient pas, peu importe qu'elle soit courante ou non.
elle ne convient pas, car, d'apres l'enonce, une solution qui convient doit etre courante.
Elle l'est dans la problematique dont il est question.
"luc2" <luc2@nospam.invalid> a écrit dans le message de news:
9uv7u0trklhtm6k3fnqtecr357s2lodtub@4ax.com...
On Tue, 11 Jan 2005 16:12:22 +0100, "Christophe Lephay"
<christophe-lephay@wanadoo.fr> wrote:
cette solution est equivalente a celle des listeners en java. or, ce
n'est pas quelque chose de courant en c++.
Soit une solution convient, soit elle ne convient pas. si elle convient,
peu
importe qu'elle soit courante ou non. Si elle ne convient pas, peu importe
qu'elle soit courante ou non.
elle ne convient pas, car, d'apres l'enonce, une solution qui convient
doit etre courante.
Elle l'est dans la problematique dont il est question.
On Tue, 11 Jan 2005 16:12:22 +0100, "Christophe Lephay" wrote:
cette solution est equivalente a celle des listeners en java. or, ce n'est pas quelque chose de courant en c++.
Soit une solution convient, soit elle ne convient pas. si elle convient, peu importe qu'elle soit courante ou non. Si elle ne convient pas, peu importe qu'elle soit courante ou non.
elle ne convient pas, car, d'apres l'enonce, une solution qui convient doit etre courante.
Elle l'est dans la problematique dont il est question.
luc2
On Tue, 11 Jan 2005 16:12:22 +0100, "Christophe Lephay" wrote:
cette solution est equivalente a celle des listeners en java. or, ce n'est pas quelque chose de courant en c++.
Soit une solution convient, soit elle ne convient pas. si elle convient, peu importe qu'elle soit courante ou non. Si elle ne convient pas, peu importe qu'elle soit courante ou non.
elle ne convient pas, car, d'apres l'enonce, une solution qui convient doit etre courante.
On Tue, 11 Jan 2005 16:12:22 +0100, "Christophe Lephay"
<christophe-lephay@wanadoo.fr> wrote:
cette solution est equivalente a celle des listeners en java. or, ce
n'est pas quelque chose de courant en c++.
Soit une solution convient, soit elle ne convient pas. si elle convient, peu
importe qu'elle soit courante ou non. Si elle ne convient pas, peu importe
qu'elle soit courante ou non.
elle ne convient pas, car, d'apres l'enonce, une solution qui convient
doit etre courante.
On Tue, 11 Jan 2005 16:12:22 +0100, "Christophe Lephay" wrote:
cette solution est equivalente a celle des listeners en java. or, ce n'est pas quelque chose de courant en c++.
Soit une solution convient, soit elle ne convient pas. si elle convient, peu importe qu'elle soit courante ou non. Si elle ne convient pas, peu importe qu'elle soit courante ou non.
elle ne convient pas, car, d'apres l'enonce, une solution qui convient doit etre courante.
luc2
On Tue, 11 Jan 2005 16:23:30 +0100, Falk Tannhäuser wrote:
La solution à ce dilemme en POO me paraît archi-classique : Quand on veux casser une dépendance circulaire, on introduit une classe de base (typiquement abstraite) supplémentaire, et on fait dépendre les deux "participants au cycle" de cette classe, au lieu d'avoir une dépendance mutuelle directe entre eux... [...]
cette solution est equivalente a celle des listeners en java. or, ce n'est pas quelque chose de courant en c++.
Cette solution me semble assez courante dans le code que j'écris ou que je suis emmené de voir...
ce n'est pas courant pour la plupart des gens.
En outre, elle est présentée dans le bouquin de GoF sur les "Design Patterns".
cela ne l'a pas empechee d'etre marginale apparemment.
On Tue, 11 Jan 2005 16:23:30 +0100, Falk Tannhäuser
<falk.tannhauser@crf.canon.fr> wrote:
La solution à ce dilemme en POO me paraît archi-classique :
Quand on veux casser une dépendance circulaire, on introduit
une classe de base (typiquement abstraite) supplémentaire,
et on fait dépendre les deux "participants au cycle" de cette
classe, au lieu d'avoir une dépendance mutuelle directe entre
eux...
[...]
cette solution est equivalente a celle des listeners en java. or, ce
n'est pas quelque chose de courant en c++.
Cette solution me semble assez courante dans le code que j'écris
ou que je suis emmené de voir...
ce n'est pas courant pour la plupart des gens.
En outre, elle est présentée
dans le bouquin de GoF sur les "Design Patterns".
cela ne l'a pas empechee d'etre marginale apparemment.
On Tue, 11 Jan 2005 16:23:30 +0100, Falk Tannhäuser wrote:
La solution à ce dilemme en POO me paraît archi-classique : Quand on veux casser une dépendance circulaire, on introduit une classe de base (typiquement abstraite) supplémentaire, et on fait dépendre les deux "participants au cycle" de cette classe, au lieu d'avoir une dépendance mutuelle directe entre eux... [...]
cette solution est equivalente a celle des listeners en java. or, ce n'est pas quelque chose de courant en c++.
Cette solution me semble assez courante dans le code que j'écris ou que je suis emmené de voir...
ce n'est pas courant pour la plupart des gens.
En outre, elle est présentée dans le bouquin de GoF sur les "Design Patterns".
cela ne l'a pas empechee d'etre marginale apparemment.
Christophe Lephay
"luc2" a écrit dans le message de news:
On Tue, 11 Jan 2005 16:23:30 +0100, Falk Tannhäuser wrote:
Cette solution me semble assez courante dans le code que j'écris ou que je suis emmené de voir...
ce n'est pas courant pour la plupart des gens.
Tu te fais une idée fausse de "la plupart des gens". Tous ceux qui gèrent une interface graphique, par exemple, utilisent des listeners (qu'ils le sachent ou non, du reste).
En outre, elle est présentée dans le bouquin de GoF sur les "Design Patterns".
cela ne l'a pas empechee d'etre marginale apparemment.
Par définition, un design pattern est une solution courante, c'est à dire non marginale. En particulier en C++, qui n'est pas un domaine completement etranger aux design patterns.
"luc2" <luc2@nospam.invalid> a écrit dans le message de news:
a108u054t3qcpkbl977v6vc30nnbnptjl5@4ax.com...
On Tue, 11 Jan 2005 16:23:30 +0100, Falk Tannhäuser
<falk.tannhauser@crf.canon.fr> wrote:
Cette solution me semble assez courante dans le code que j'écris
ou que je suis emmené de voir...
ce n'est pas courant pour la plupart des gens.
Tu te fais une idée fausse de "la plupart des gens". Tous ceux qui gèrent
une interface graphique, par exemple, utilisent des listeners (qu'ils le
sachent ou non, du reste).
En outre, elle est présentée
dans le bouquin de GoF sur les "Design Patterns".
cela ne l'a pas empechee d'etre marginale apparemment.
Par définition, un design pattern est une solution courante, c'est à dire
non marginale. En particulier en C++, qui n'est pas un domaine completement
etranger aux design patterns.
On Tue, 11 Jan 2005 16:23:30 +0100, Falk Tannhäuser wrote:
Cette solution me semble assez courante dans le code que j'écris ou que je suis emmené de voir...
ce n'est pas courant pour la plupart des gens.
Tu te fais une idée fausse de "la plupart des gens". Tous ceux qui gèrent une interface graphique, par exemple, utilisent des listeners (qu'ils le sachent ou non, du reste).
En outre, elle est présentée dans le bouquin de GoF sur les "Design Patterns".
cela ne l'a pas empechee d'etre marginale apparemment.
Par définition, un design pattern est une solution courante, c'est à dire non marginale. En particulier en C++, qui n'est pas un domaine completement etranger aux design patterns.
luc2
On Tue, 11 Jan 2005 16:36:54 +0100, Falk Tannhäuser wrote:
Ah? La conception est toujours une affaire de compromis entre differents objectifs contradictoires, dont la simplicite et la generalite. Si tous les objets d'une classe doivent etre reference par un autre objet, le plus simple est de les faire s'inscrire dans les constructeurs et desinscrire dans le destructeur.
non. si c'est le constructeur de l'objet qui inscrit l'objet dans la liste, alors cela signifie que l'objet SAIT qu'il est dans une liste. or, il ne doit pas le savoir.
La résolution des problèmes s'accomode souvent assez mal avec les dogmes religieux.
Pour moi, le but / la raison d'être de la POO est de permettre de gérer et de minimiser les dépendances entre les modules du soft. En particulier, il s'agit d'éliminer les dépendances circulaires. Je suis d'accord avec luc2 qu'un thread n'a pas à connaître la liste à laquelle il appartient - l'introduction d'un "listener" (ce que semble revenir au "Observer Pattern") constitue pour moi une solution satisfaisante et assez classique / bien connue.
pour trouver ca dans un code en c++, il faut se lever de bonne heure, alors qu'on en rencontre partout en java.
On Tue, 11 Jan 2005 16:36:54 +0100, Falk Tannhäuser
<falk.tannhauser@crf.canon.fr> wrote:
Ah? La conception est toujours une affaire de compromis entre
differents objectifs contradictoires, dont la simplicite et la
generalite. Si tous les objets d'une classe doivent etre reference
par un autre objet, le plus simple est de les faire s'inscrire dans
les constructeurs et desinscrire dans le destructeur.
non. si c'est le constructeur de l'objet qui inscrit l'objet dans la
liste, alors cela signifie que l'objet SAIT qu'il est dans une liste.
or, il ne doit pas le savoir.
La résolution des problèmes s'accomode souvent assez mal avec les dogmes
religieux.
Pour moi, le but / la raison d'être de la POO est de permettre de gérer
et de minimiser les dépendances entre les modules du soft. En particulier,
il s'agit d'éliminer les dépendances circulaires. Je suis d'accord avec
luc2 qu'un thread n'a pas à connaître la liste à laquelle il appartient
- l'introduction d'un "listener" (ce que semble revenir au "Observer
Pattern") constitue pour moi une solution satisfaisante et assez classique
/ bien connue.
pour trouver ca dans un code en c++, il faut se lever de bonne heure,
alors qu'on en rencontre partout en java.
On Tue, 11 Jan 2005 16:36:54 +0100, Falk Tannhäuser wrote:
Ah? La conception est toujours une affaire de compromis entre differents objectifs contradictoires, dont la simplicite et la generalite. Si tous les objets d'une classe doivent etre reference par un autre objet, le plus simple est de les faire s'inscrire dans les constructeurs et desinscrire dans le destructeur.
non. si c'est le constructeur de l'objet qui inscrit l'objet dans la liste, alors cela signifie que l'objet SAIT qu'il est dans une liste. or, il ne doit pas le savoir.
La résolution des problèmes s'accomode souvent assez mal avec les dogmes religieux.
Pour moi, le but / la raison d'être de la POO est de permettre de gérer et de minimiser les dépendances entre les modules du soft. En particulier, il s'agit d'éliminer les dépendances circulaires. Je suis d'accord avec luc2 qu'un thread n'a pas à connaître la liste à laquelle il appartient - l'introduction d'un "listener" (ce que semble revenir au "Observer Pattern") constitue pour moi une solution satisfaisante et assez classique / bien connue.
pour trouver ca dans un code en c++, il faut se lever de bonne heure, alors qu'on en rencontre partout en java.
Christophe Lephay
"luc2" a écrit dans le message de news:
pour trouver ca dans un code en c++, il faut se lever de bonne heure, alors qu'on en rencontre partout en java.
Il suffit de s'interesser au code de n'importe quelle application gerant une interface graphique. Contrairement à ce que tu as l'air de penser, il n'est pas besoin de se lever de bonne heure pour trouver une de ces dernières.
"luc2" <luc2@nospam.invalid> a écrit dans le message de news:
i508u01h5tn1i65lpk5hhcgbn7ahc83jtb@4ax.com...
pour trouver ca dans un code en c++, il faut se lever de bonne heure,
alors qu'on en rencontre partout en java.
Il suffit de s'interesser au code de n'importe quelle application gerant une
interface graphique. Contrairement à ce que tu as l'air de penser, il n'est
pas besoin de se lever de bonne heure pour trouver une de ces dernières.
pour trouver ca dans un code en c++, il faut se lever de bonne heure, alors qu'on en rencontre partout en java.
Il suffit de s'interesser au code de n'importe quelle application gerant une interface graphique. Contrairement à ce que tu as l'air de penser, il n'est pas besoin de se lever de bonne heure pour trouver une de ces dernières.
