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 ?
les observeurs sont classiques dans la programmation orientee objet en general, mais en pratique, presqu'aucun programme en c++ ne les utilise. c'est un fait.
Oui, et c'est même un fait tout droit sorti de ton chapeau, pour être plus précis.
"luc2" <luc2@nospam.invalid> a écrit dans le message de news:
9808u0levd9m804dsubhcqfmjhedrfkgif@4ax.com...
les observeurs sont classiques dans la programmation orientee objet en
general, mais en pratique, presqu'aucun programme en c++ ne les
utilise. c'est un fait.
Oui, et c'est même un fait tout droit sorti de ton chapeau, pour être plus
précis.
les observeurs sont classiques dans la programmation orientee objet en general, mais en pratique, presqu'aucun programme en c++ ne les utilise. c'est un fait.
Oui, et c'est même un fait tout droit sorti de ton chapeau, pour être plus précis.
luc2
On Tue, 11 Jan 2005 16:55:11 +0100, Jean-Sebastien Mouret wrote:
des exemples semblables, on en trouve a la pelle. nier que les listeners ne sont pas courant en c++, c'est etre de mauvaise foi. parmi les programmes que tu as connu, quel est le pourcentage de ceux qui utilisent des listeners ?
en java : 100% en c++ : 0%
pour tout le monde, on a toujours environ 100% pour le java, et environ 0% pour le c++. bref, les listeners ne sont pas courants en c++.
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
les observeurs sont classiques dans la programmation orientee objet en general, mais en pratique, presqu'aucun programme en c++ ne les utilise. c'est un fait.
On Tue, 11 Jan 2005 16:55:11 +0100, Jean-Sebastien Mouret
<js@mouret.org> wrote:
des exemples semblables, on en trouve a la pelle. nier que les
listeners ne sont pas courant en c++, c'est etre de mauvaise foi.
parmi les programmes que tu as connu, quel est le pourcentage de ceux
qui utilisent des listeners ?
en java : 100%
en c++ : 0%
pour tout le monde, on a toujours environ 100% pour le java, et
environ 0% pour le c++. bref, les listeners ne sont pas courants en
c++.
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
les observeurs sont classiques dans la programmation orientee objet en
general, mais en pratique, presqu'aucun programme en c++ ne les
utilise. c'est un fait.
On Tue, 11 Jan 2005 16:55:11 +0100, Jean-Sebastien Mouret wrote:
des exemples semblables, on en trouve a la pelle. nier que les listeners ne sont pas courant en c++, c'est etre de mauvaise foi. parmi les programmes que tu as connu, quel est le pourcentage de ceux qui utilisent des listeners ?
en java : 100% en c++ : 0%
pour tout le monde, on a toujours environ 100% pour le java, et environ 0% pour le c++. bref, les listeners ne sont pas courants en c++.
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
les observeurs sont classiques dans la programmation orientee objet en general, mais en pratique, presqu'aucun programme en c++ ne les utilise. c'est un fait.
luc2
On Tue, 11 Jan 2005 17:15:11 +0100, "Christophe Lephay" wrote:
comme les autres, tu confonds "marginaux" et "inexistant". les listeners ne sont pas "inexistants" en c++, mais ils sont "marginaux".
un petit exemple :
l'api du java grouille de listeners. par exemple, quand on veut faire un bouton cliquable, c'est un listener qui est declenche quand on clique sur le bouton.
en c++, prenons par exemple l'api de microsoft pour les boutons. on peut constater que l'action du clic n'est pas geree par un listener.
des exemples semblables, on en trouve a la pelle. nier que les listeners ne sont pas courant en c++, c'est etre de mauvaise foi. parmi les programmes que tu as connu, quel est le pourcentage de ceux qui utilisent des listeners ?
en java : 100% en c++ : 0%
pour tout le monde, on a toujours environ 100% pour le java, et environ 0% pour le c++. bref, les listeners ne sont pas courants en c++.
Visiblement tu as du mal à raisonner sur les cas généraux. Tous les exemples de listeners que tu cites de Java concernent des domaines qui ne sont pas couverts par le langage C++. La notion d'interface graphique ou de thread n'est pas couverte par le langage C++.
si. pour le bouton, j'ai parle de l'api de microsoft en c++.
Par contre, dès qu'on doit programmer en C++ la gestion d'une interface graphique ou des threads, il n'y a pas de raison que la solution C++ diffère d'une autre utilisée en Java pour adresser le même problème.
et bien en pratique, ca differe mon cher.
Les listeners ne sont pas spécifiques à Java, ils sont juste un pattern OO implémenté nativement dans Java pour des taches qui ne sont pas définies dans le standard du C++.
si. les boutons sont definis en c++, dans l'api de microsoft.
Le fait qu'ils soient plus fréquents en Java qu'en C++ n'est vrai que tant que tu restreins le langage à des applications *spécifiquement différentes*, ce qui fait que ta généralité ne vaut rien car elle n'est vraie que dans la spécificité des taches auxquelles tu t'attaquerais avec tel ou tel langage.
ah bon ? ma generalisation est specifique ? prouve-le.
La différence entre C++ et Java, face à la même problématique, c'est que ce pattern fait partie de l'api de Java, tandis qu'il ne fait pas partie de l'api du C++, ce qui laisse le choix de tel design plutôt qu'un autre. Qu'un tel choix existe n'implique aucunement que ce n'est pas un idiome C++.
tu continues a confondre "listeners existants" et "listeners courants". je n'ai jamais dit qu'il etait impossible de faire de listeners en c++. meme si on a le CHOIX d'en faire, en pratique, peu de personnes en font.
On est loin du 0% que tu sors de ton chapeau.
dis-moi alors quel est le bon pourcentage te concernant ?
On Tue, 11 Jan 2005 17:15:11 +0100, "Christophe Lephay"
<christophe-lephay@wanadoo.fr> wrote:
comme les autres, tu confonds "marginaux" et "inexistant". les
listeners ne sont pas "inexistants" en c++, mais ils sont "marginaux".
un petit exemple :
l'api du java grouille de listeners. par exemple, quand on veut faire
un bouton cliquable, c'est un listener qui est declenche quand on
clique sur le bouton.
en c++, prenons par exemple l'api de microsoft pour les boutons. on
peut constater que l'action du clic n'est pas geree par un listener.
des exemples semblables, on en trouve a la pelle. nier que les
listeners ne sont pas courant en c++, c'est etre de mauvaise foi.
parmi les programmes que tu as connu, quel est le pourcentage de ceux
qui utilisent des listeners ?
en java : 100%
en c++ : 0%
pour tout le monde, on a toujours environ 100% pour le java, et
environ 0% pour le c++. bref, les listeners ne sont pas courants en
c++.
Visiblement tu as du mal à raisonner sur les cas généraux. Tous les exemples
de listeners que tu cites de Java concernent des domaines qui ne sont pas
couverts par le langage C++. La notion d'interface graphique ou de thread
n'est pas couverte par le langage C++.
si. pour le bouton, j'ai parle de l'api de microsoft en c++.
Par contre, dès qu'on doit programmer en C++ la gestion d'une interface
graphique ou des threads, il n'y a pas de raison que la solution C++ diffère
d'une autre utilisée en Java pour adresser le même problème.
et bien en pratique, ca differe mon cher.
Les listeners ne sont pas spécifiques à Java, ils sont juste un pattern OO
implémenté nativement dans Java pour des taches qui ne sont pas définies
dans le standard du C++.
si. les boutons sont definis en c++, dans l'api de microsoft.
Le fait qu'ils soient plus fréquents en Java qu'en
C++ n'est vrai que tant que tu restreins le langage à des applications
*spécifiquement différentes*, ce qui fait que ta généralité ne vaut rien car
elle n'est vraie que dans la spécificité des taches auxquelles tu
t'attaquerais avec tel ou tel langage.
ah bon ? ma generalisation est specifique ? prouve-le.
La différence entre C++ et Java, face à la même problématique, c'est que ce
pattern fait partie de l'api de Java, tandis qu'il ne fait pas partie de
l'api du C++, ce qui laisse le choix de tel design plutôt qu'un autre. Qu'un
tel choix existe n'implique aucunement que ce n'est pas un idiome C++.
tu continues a confondre "listeners existants" et "listeners
courants". je n'ai jamais dit qu'il etait impossible de faire de
listeners en c++. meme si on a le CHOIX d'en faire, en pratique, peu
de personnes en font.
On est loin du 0% que tu sors de ton chapeau.
dis-moi alors quel est le bon pourcentage te concernant ?
On Tue, 11 Jan 2005 17:15:11 +0100, "Christophe Lephay" wrote:
comme les autres, tu confonds "marginaux" et "inexistant". les listeners ne sont pas "inexistants" en c++, mais ils sont "marginaux".
un petit exemple :
l'api du java grouille de listeners. par exemple, quand on veut faire un bouton cliquable, c'est un listener qui est declenche quand on clique sur le bouton.
en c++, prenons par exemple l'api de microsoft pour les boutons. on peut constater que l'action du clic n'est pas geree par un listener.
des exemples semblables, on en trouve a la pelle. nier que les listeners ne sont pas courant en c++, c'est etre de mauvaise foi. parmi les programmes que tu as connu, quel est le pourcentage de ceux qui utilisent des listeners ?
en java : 100% en c++ : 0%
pour tout le monde, on a toujours environ 100% pour le java, et environ 0% pour le c++. bref, les listeners ne sont pas courants en c++.
Visiblement tu as du mal à raisonner sur les cas généraux. Tous les exemples de listeners que tu cites de Java concernent des domaines qui ne sont pas couverts par le langage C++. La notion d'interface graphique ou de thread n'est pas couverte par le langage C++.
si. pour le bouton, j'ai parle de l'api de microsoft en c++.
Par contre, dès qu'on doit programmer en C++ la gestion d'une interface graphique ou des threads, il n'y a pas de raison que la solution C++ diffère d'une autre utilisée en Java pour adresser le même problème.
et bien en pratique, ca differe mon cher.
Les listeners ne sont pas spécifiques à Java, ils sont juste un pattern OO implémenté nativement dans Java pour des taches qui ne sont pas définies dans le standard du C++.
si. les boutons sont definis en c++, dans l'api de microsoft.
Le fait qu'ils soient plus fréquents en Java qu'en C++ n'est vrai que tant que tu restreins le langage à des applications *spécifiquement différentes*, ce qui fait que ta généralité ne vaut rien car elle n'est vraie que dans la spécificité des taches auxquelles tu t'attaquerais avec tel ou tel langage.
ah bon ? ma generalisation est specifique ? prouve-le.
La différence entre C++ et Java, face à la même problématique, c'est que ce pattern fait partie de l'api de Java, tandis qu'il ne fait pas partie de l'api du C++, ce qui laisse le choix de tel design plutôt qu'un autre. Qu'un tel choix existe n'implique aucunement que ce n'est pas un idiome C++.
tu continues a confondre "listeners existants" et "listeners courants". je n'ai jamais dit qu'il etait impossible de faire de listeners en c++. meme si on a le CHOIX d'en faire, en pratique, peu de personnes en font.
On est loin du 0% que tu sors de ton chapeau.
dis-moi alors quel est le bon pourcentage te concernant ?
Christophe Lephay
"luc2" a écrit dans le message de news:
Visiblement tu as du mal à raisonner sur les cas généraux. Tous les exemples de listeners que tu cites de Java concernent des domaines qui ne sont pas couverts par le langage C++. La notion d'interface graphique ou de thread n'est pas couverte par le langage C++.
si. pour le bouton, j'ai parle de l'api de microsoft en c++.
L'api windows définie par microsoft, y compris via ses MFC ne font pas partie du langage C++. C'est comme si tu écrivais une application Java et pretendait apres coup qu'elle fait partie du standard Java. Qui plus est, même si j'ai plus utilisé les frameworks borland, il me semble bien que microsoft fait un usage intensif du modele observer. C'est le cas, par exemple, du modele document/view qui y est largement répandu.
Par contre, dès qu'on doit programmer en C++ la gestion d'une interface graphique ou des threads, il n'y a pas de raison que la solution C++ diffère d'une autre utilisée en Java pour adresser le même problème.
et bien en pratique, ca differe mon cher.
C'est toi qui le dit.
Les listeners ne sont pas spécifiques à Java, ils sont juste un pattern OO implémenté nativement dans Java pour des taches qui ne sont pas définies dans le standard du C++.
si. les boutons sont definis en c++, dans l'api de microsoft.
Le C++ n'est pas défini par microsoft.
Le fait qu'ils soient plus fréquents en Java qu'en C++ n'est vrai que tant que tu restreins le langage à des applications *spécifiquement différentes*, ce qui fait que ta généralité ne vaut rien car elle n'est vraie que dans la spécificité des taches auxquelles tu t'attaquerais avec tel ou tel langage.
ah bon ? ma generalisation est specifique ? prouve-le.
Trouve-t-on des listeners dans un programme Java qui ne ferait que compter de 1 à 1000 ? Réponse : non.
Trouve-ton des listeners dans une application graphique C++ ? Réponse : oui.
Ta généralisation n'est donc vraie que tant qu'on confine Java et C++ à des domaines distincts, spécifiques.
La différence entre C++ et Java, face à la même problématique, c'est que ce pattern fait partie de l'api de Java, tandis qu'il ne fait pas partie de l'api du C++, ce qui laisse le choix de tel design plutôt qu'un autre. Qu'un tel choix existe n'implique aucunement que ce n'est pas un idiome C++.
tu continues a confondre "listeners existants" et "listeners courants". je n'ai jamais dit qu'il etait impossible de faire de listeners en c++. meme si on a le CHOIX d'en faire, en pratique, peu de personnes en font.
Je ne confonds rien du tout. En pratique, tout le monde en utilise dçs lors que le programme gère une interface graphique, qu'il le sache ou non car celà peut très bien être completement encapsulé dans le framework.
On est loin du 0% que tu sors de ton chapeau.
dis-moi alors quel est le bon pourcentage te concernant ?
Je ne vais pas à mon tour un nombre sorti de mon chapeau. Par contre, je ne connais pas un seul framework GUI en C++ qui n'utilise pas de listeners. Mais je n'ai pas la prétention de tous les connaitre, et je t'invite à m'en citer qui n'en feraient pas l'usage.
Dans tous les cas, je vais arreter ici ma contribution. Tu as eu les réponses à ta question. Si tu décides de les ignorer car ils iraient à l'encontre de ton a priori, qui te permettraient par exemple d'affirmer à quel point le C++ n'est pas "propre" ou ne permet pas de faire de la POO, je pense que personne ne peut rien pour toi.
Ce ne serait pas la première fois qu'un dogme est établi sur la base d'un autre dogme.
Tu as eu les réponses que tu demandais. Maintenant, tu en fais ce que tu veux.
Fin de la discussion (en tout cas avec moi).
"luc2" <luc2@nospam.invalid> a écrit dans le message de news:
cr08u0pjit9eskvra67dfna4sjn0l4urlo@4ax.com...
Visiblement tu as du mal à raisonner sur les cas généraux. Tous les
exemples
de listeners que tu cites de Java concernent des domaines qui ne sont pas
couverts par le langage C++. La notion d'interface graphique ou de thread
n'est pas couverte par le langage C++.
si. pour le bouton, j'ai parle de l'api de microsoft en c++.
L'api windows définie par microsoft, y compris via ses MFC ne font pas
partie du langage C++. C'est comme si tu écrivais une application Java et
pretendait apres coup qu'elle fait partie du standard Java. Qui plus est,
même si j'ai plus utilisé les frameworks borland, il me semble bien que
microsoft fait un usage intensif du modele observer. C'est le cas, par
exemple, du modele document/view qui y est largement répandu.
Par contre, dès qu'on doit programmer en C++ la gestion d'une interface
graphique ou des threads, il n'y a pas de raison que la solution C++
diffère
d'une autre utilisée en Java pour adresser le même problème.
et bien en pratique, ca differe mon cher.
C'est toi qui le dit.
Les listeners ne sont pas spécifiques à Java, ils sont juste un pattern OO
implémenté nativement dans Java pour des taches qui ne sont pas définies
dans le standard du C++.
si. les boutons sont definis en c++, dans l'api de microsoft.
Le C++ n'est pas défini par microsoft.
Le fait qu'ils soient plus fréquents en Java qu'en
C++ n'est vrai que tant que tu restreins le langage à des applications
*spécifiquement différentes*, ce qui fait que ta généralité ne vaut rien
car
elle n'est vraie que dans la spécificité des taches auxquelles tu
t'attaquerais avec tel ou tel langage.
ah bon ? ma generalisation est specifique ? prouve-le.
Trouve-t-on des listeners dans un programme Java qui ne ferait que compter
de 1 à 1000 ? Réponse : non.
Trouve-ton des listeners dans une application graphique C++ ? Réponse : oui.
Ta généralisation n'est donc vraie que tant qu'on confine Java et C++ à des
domaines distincts, spécifiques.
La différence entre C++ et Java, face à la même problématique, c'est que
ce
pattern fait partie de l'api de Java, tandis qu'il ne fait pas partie de
l'api du C++, ce qui laisse le choix de tel design plutôt qu'un autre.
Qu'un
tel choix existe n'implique aucunement que ce n'est pas un idiome C++.
tu continues a confondre "listeners existants" et "listeners
courants". je n'ai jamais dit qu'il etait impossible de faire de
listeners en c++. meme si on a le CHOIX d'en faire, en pratique, peu
de personnes en font.
Je ne confonds rien du tout. En pratique, tout le monde en utilise dçs lors
que le programme gère une interface graphique, qu'il le sache ou non car
celà peut très bien être completement encapsulé dans le framework.
On est loin du 0% que tu sors de ton chapeau.
dis-moi alors quel est le bon pourcentage te concernant ?
Je ne vais pas à mon tour un nombre sorti de mon chapeau. Par contre, je ne
connais pas un seul framework GUI en C++ qui n'utilise pas de listeners.
Mais je n'ai pas la prétention de tous les connaitre, et je t'invite à m'en
citer qui n'en feraient pas l'usage.
Dans tous les cas, je vais arreter ici ma contribution. Tu as eu les
réponses à ta question. Si tu décides de les ignorer car ils iraient à
l'encontre de ton a priori, qui te permettraient par exemple d'affirmer à
quel point le C++ n'est pas "propre" ou ne permet pas de faire de la POO, je
pense que personne ne peut rien pour toi.
Ce ne serait pas la première fois qu'un dogme est établi sur la base d'un
autre dogme.
Tu as eu les réponses que tu demandais. Maintenant, tu en fais ce que tu
veux.
Visiblement tu as du mal à raisonner sur les cas généraux. Tous les exemples de listeners que tu cites de Java concernent des domaines qui ne sont pas couverts par le langage C++. La notion d'interface graphique ou de thread n'est pas couverte par le langage C++.
si. pour le bouton, j'ai parle de l'api de microsoft en c++.
L'api windows définie par microsoft, y compris via ses MFC ne font pas partie du langage C++. C'est comme si tu écrivais une application Java et pretendait apres coup qu'elle fait partie du standard Java. Qui plus est, même si j'ai plus utilisé les frameworks borland, il me semble bien que microsoft fait un usage intensif du modele observer. C'est le cas, par exemple, du modele document/view qui y est largement répandu.
Par contre, dès qu'on doit programmer en C++ la gestion d'une interface graphique ou des threads, il n'y a pas de raison que la solution C++ diffère d'une autre utilisée en Java pour adresser le même problème.
et bien en pratique, ca differe mon cher.
C'est toi qui le dit.
Les listeners ne sont pas spécifiques à Java, ils sont juste un pattern OO implémenté nativement dans Java pour des taches qui ne sont pas définies dans le standard du C++.
si. les boutons sont definis en c++, dans l'api de microsoft.
Le C++ n'est pas défini par microsoft.
Le fait qu'ils soient plus fréquents en Java qu'en C++ n'est vrai que tant que tu restreins le langage à des applications *spécifiquement différentes*, ce qui fait que ta généralité ne vaut rien car elle n'est vraie que dans la spécificité des taches auxquelles tu t'attaquerais avec tel ou tel langage.
ah bon ? ma generalisation est specifique ? prouve-le.
Trouve-t-on des listeners dans un programme Java qui ne ferait que compter de 1 à 1000 ? Réponse : non.
Trouve-ton des listeners dans une application graphique C++ ? Réponse : oui.
Ta généralisation n'est donc vraie que tant qu'on confine Java et C++ à des domaines distincts, spécifiques.
La différence entre C++ et Java, face à la même problématique, c'est que ce pattern fait partie de l'api de Java, tandis qu'il ne fait pas partie de l'api du C++, ce qui laisse le choix de tel design plutôt qu'un autre. Qu'un tel choix existe n'implique aucunement que ce n'est pas un idiome C++.
tu continues a confondre "listeners existants" et "listeners courants". je n'ai jamais dit qu'il etait impossible de faire de listeners en c++. meme si on a le CHOIX d'en faire, en pratique, peu de personnes en font.
Je ne confonds rien du tout. En pratique, tout le monde en utilise dçs lors que le programme gère une interface graphique, qu'il le sache ou non car celà peut très bien être completement encapsulé dans le framework.
On est loin du 0% que tu sors de ton chapeau.
dis-moi alors quel est le bon pourcentage te concernant ?
Je ne vais pas à mon tour un nombre sorti de mon chapeau. Par contre, je ne connais pas un seul framework GUI en C++ qui n'utilise pas de listeners. Mais je n'ai pas la prétention de tous les connaitre, et je t'invite à m'en citer qui n'en feraient pas l'usage.
Dans tous les cas, je vais arreter ici ma contribution. Tu as eu les réponses à ta question. Si tu décides de les ignorer car ils iraient à l'encontre de ton a priori, qui te permettraient par exemple d'affirmer à quel point le C++ n'est pas "propre" ou ne permet pas de faire de la POO, je pense que personne ne peut rien pour toi.
Ce ne serait pas la première fois qu'un dogme est établi sur la base d'un autre dogme.
Tu as eu les réponses que tu demandais. Maintenant, tu en fais ce que tu veux.
Fin de la discussion (en tout cas avec moi).
luc2
On Tue, 11 Jan 2005 17:28:17 +0100, "Christophe Lephay" wrote:
Je dis "par définition" car c'est à celà que sert un listener, gerer la liste des objets à observer.
mouais... je vois que tu ne sais meme pas ce qu'est un listener...
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.
bon. toujours pas de solution pour le c++ alors...
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).
c'est bien ce que je pensais : tu ne sais pas ce qu'est un listener. l'api ne peut pas nous empecher de creer des listener. c'est quelque chose que l'on cree conceptuellement.
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.
je crois que j'ai deja ete assez explicite dessus : un objet n'a pas a contenir une liste de lui-meme.
On Tue, 11 Jan 2005 17:28:17 +0100, "Christophe Lephay"
<christophe-lephay@wanadoo.fr> wrote:
Je dis "par définition" car c'est à celà que sert un listener, gerer la
liste des objets à observer.
mouais... je vois que tu ne sais meme pas ce qu'est un listener...
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.
bon. toujours pas de solution pour le c++ alors...
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).
c'est bien ce que je pensais : tu ne sais pas ce qu'est un listener.
l'api ne peut pas nous empecher de creer des listener. c'est quelque
chose que l'on cree conceptuellement.
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.
je crois que j'ai deja ete assez explicite dessus : un objet n'a pas a
contenir une liste de lui-meme.
On Tue, 11 Jan 2005 17:28:17 +0100, "Christophe Lephay" wrote:
Je dis "par définition" car c'est à celà que sert un listener, gerer la liste des objets à observer.
mouais... je vois que tu ne sais meme pas ce qu'est un listener...
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.
bon. toujours pas de solution pour le c++ alors...
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).
c'est bien ce que je pensais : tu ne sais pas ce qu'est un listener. l'api ne peut pas nous empecher de creer des listener. c'est quelque chose que l'on cree conceptuellement.
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.
je crois que j'ai deja ete assez explicite dessus : un objet n'a pas a contenir une liste de lui-meme.
luc2
On Tue, 11 Jan 2005 17:33:18 +0100, "Christophe Lephay" wrote:
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.
non. le pretexte, c'est qu'il n'est pas courant en c++.
On Tue, 11 Jan 2005 17:33:18 +0100, "Christophe Lephay"
<christophe-lephay@wanadoo.fr> wrote:
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.
non. le pretexte, c'est qu'il n'est pas courant en c++.
On Tue, 11 Jan 2005 17:33:18 +0100, "Christophe Lephay" wrote:
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.
non. le pretexte, c'est qu'il n'est pas courant en c++.
luc2
On Tue, 11 Jan 2005 17:34:03 +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.
mais le mot "courante" de l'enonce voulait dire "courante EN GENERAL".
On Tue, 11 Jan 2005 17:34:03 +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.
mais le mot "courante" de l'enonce voulait dire "courante EN GENERAL".
On Tue, 11 Jan 2005 17:34:03 +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.
mais le mot "courante" de l'enonce voulait dire "courante EN GENERAL".
luc2
On Tue, 11 Jan 2005 17:36:59 +0100, "Christophe Lephay" 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).
prouve-le.
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.
non. des tas de cours et de livres initient les gens au c++ sans jamais parler de design pattern. la majorite des personnes n'en a jamais entendu parler.
On Tue, 11 Jan 2005 17:36:59 +0100, "Christophe Lephay"
<christophe-lephay@wanadoo.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).
prouve-le.
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.
non. des tas de cours et de livres initient les gens au c++ sans
jamais parler de design pattern. la majorite des personnes n'en a
jamais entendu parler.
On Tue, 11 Jan 2005 17:36:59 +0100, "Christophe Lephay" 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).
prouve-le.
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.
non. des tas de cours et de livres initient les gens au c++ sans jamais parler de design pattern. la majorite des personnes n'en a jamais entendu parler.
Franck Guillaud
J'invite les contributeurs de ce thread à consulter l'URL suivante :
http://lucii.free.fr/
Vous en saurez alors un peu plus sur la nature du personnage. Après, libre à vous de continuer à tenter d'argumenter.
Franck,e-trollomètre
J'invite les contributeurs de ce thread à consulter l'URL suivante :
http://lucii.free.fr/
Vous en saurez alors un peu plus sur la nature du personnage.
Après, libre à vous de continuer à tenter d'argumenter.
J'invite les contributeurs de ce thread à consulter l'URL suivante :
http://lucii.free.fr/
Vous en saurez alors un peu plus sur la nature du personnage. Après, libre à vous de continuer à tenter d'argumenter.
Franck,e-trollomètre
luc2
On Tue, 11 Jan 2005 17:38:25 +0100, "Christophe Lephay" wrote:
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.
prouve-le.
en ce qui me concerne, 0% des interfaces graphiques c++ ne contiennent de listener. il en est de meme pour tout le monde, et pour toi aussi.
On Tue, 11 Jan 2005 17:38:25 +0100, "Christophe Lephay"
<christophe-lephay@wanadoo.fr> wrote:
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.
prouve-le.
en ce qui me concerne, 0% des interfaces graphiques c++ ne contiennent
de listener. il en est de meme pour tout le monde, et pour toi aussi.
On Tue, 11 Jan 2005 17:38:25 +0100, "Christophe Lephay" wrote:
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.
prouve-le.
en ce qui me concerne, 0% des interfaces graphiques c++ ne contiennent de listener. il en est de meme pour tout le monde, et pour toi aussi.
