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 ?
| c'est un fait. en pratique en c++, presque personne n'utilise | d'observateur.
C'est un fait que tu as observé entre les quatre murs qui forment ta chambre où est-ce que tu es allé voir dans tous les programmes C++ ?
-- Gaby
Alexandre
dis-moi quel pourcentage de programmes c++ contiennent des observeurs ?
par rapport au pourcentage de programmes C++ qui utilisent la poo ? Pas mal. Par rapport au total des programmes C++. Pas tant que ça. On peut très bien faire du C++ sans faire de POO (ce qui n'est pas le cas de java par ex), ce qui ne veut pas dire que c'est bien ou mal, mais c'est le cas. Regardes la bibliothèque standard du C++, pas si OO que ça, non ?
dis-moi quel pourcentage de programmes c++ contiennent des observeurs
?
par rapport au pourcentage de programmes C++ qui utilisent la poo ? Pas mal.
Par rapport au total des programmes C++. Pas tant que ça. On peut très bien
faire du C++ sans faire de POO (ce qui n'est pas le cas de java par ex), ce
qui ne veut pas dire que c'est bien ou mal, mais c'est le cas. Regardes la
bibliothèque standard du C++, pas si OO que ça, non ?
dis-moi quel pourcentage de programmes c++ contiennent des observeurs ?
par rapport au pourcentage de programmes C++ qui utilisent la poo ? Pas mal. Par rapport au total des programmes C++. Pas tant que ça. On peut très bien faire du C++ sans faire de POO (ce qui n'est pas le cas de java par ex), ce qui ne veut pas dire que c'est bien ou mal, mais c'est le cas. Regardes la bibliothèque standard du C++, pas si OO que ça, non ?
luc2
On Tue, 11 Jan 2005 18:39:35 +0100, "Fabien Garcia" wrote:
vraiment ? ca vous semble coherent a vous qu'un objet contienne une liste de lui-meme ?
Oui, si la conception d'une application utilisant cet objet le necessite.
et d'apres l'enonce ? est-ce que c'est necessaire ?
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 ?
Non, mais un thread_observe (ce que tu semble demander) peut heriter de la clase thread et utiliser une liste de lui meme. Tu ne semble pas vouloir un thread mais un thread qui a un comportement specifique, defini donc un objet qui a ce comportement.
c'est une solution qui me plait moyennement, mais c'est une solution. je l'ai d'ailleurs devoilee avant de lire ce post.
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 penses
quand je disais "je pense", c'etait ironique. c'est comme quand je dis "chez moi, 1+1 fait 2".
d'ailleurs, on peut voir que j'avais RAISON de penser cela, vu que vous semblez tres bien comprendre le probleme, etant donne qu'aucun d'entre vous n'a insiste pour laisser la liste a l'interieur de l'objet. de plus, si on ne parle que de toi fabien garcia, tu as encore fait mieux que comprendre le probleme, puisque tu as carrement donne la solution.
conclusion : j'avais RAISON de penser que vous voyiez tres bien le probleme.
vous en avez deja suffisamment pour raisonner : un objet faisant partie d'une liste n'a pas a contenir la liste elle-meme.
Sauf s'il doit appeler une methode de la liste, ce qui dans ton cas ne peut etre evite que par un objet qui gererait la liste.
non, il y avait plusieurs solutions.
On Tue, 11 Jan 2005 18:39:35 +0100, "Fabien Garcia"
<nospampliz@no.spam.city> wrote:
vraiment ? ca vous semble coherent a vous qu'un objet contienne une
liste de lui-meme ?
Oui, si la conception d'une application utilisant cet objet le necessite.
et d'apres l'enonce ? est-ce que c'est necessaire ?
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 ?
Non, mais un thread_observe (ce que tu semble demander) peut heriter de la
clase thread
et utiliser une liste de lui meme. Tu ne semble pas vouloir un thread mais
un thread qui a un comportement specifique, defini donc un objet qui a ce
comportement.
c'est une solution qui me plait moyennement, mais c'est une solution.
je l'ai d'ailleurs devoilee avant de lire ce post.
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 penses
quand je disais "je pense", c'etait ironique. c'est comme quand je dis
"chez moi, 1+1 fait 2".
d'ailleurs, on peut voir que j'avais RAISON de penser cela, vu que
vous semblez tres bien comprendre le probleme, etant donne qu'aucun
d'entre vous n'a insiste pour laisser la liste a l'interieur de
l'objet. de plus, si on ne parle que de toi fabien garcia, tu as
encore fait mieux que comprendre le probleme, puisque tu as carrement
donne la solution.
conclusion : j'avais RAISON de penser que vous voyiez tres bien le
probleme.
vous en avez deja suffisamment pour raisonner : un objet faisant
partie d'une liste n'a pas a contenir la liste elle-meme.
Sauf s'il doit appeler une methode de la liste, ce qui dans ton cas ne
peut etre evite que par un objet qui gererait la liste.
On Tue, 11 Jan 2005 18:39:35 +0100, "Fabien Garcia" wrote:
vraiment ? ca vous semble coherent a vous qu'un objet contienne une liste de lui-meme ?
Oui, si la conception d'une application utilisant cet objet le necessite.
et d'apres l'enonce ? est-ce que c'est necessaire ?
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 ?
Non, mais un thread_observe (ce que tu semble demander) peut heriter de la clase thread et utiliser une liste de lui meme. Tu ne semble pas vouloir un thread mais un thread qui a un comportement specifique, defini donc un objet qui a ce comportement.
c'est une solution qui me plait moyennement, mais c'est une solution. je l'ai d'ailleurs devoilee avant de lire ce post.
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 penses
quand je disais "je pense", c'etait ironique. c'est comme quand je dis "chez moi, 1+1 fait 2".
d'ailleurs, on peut voir que j'avais RAISON de penser cela, vu que vous semblez tres bien comprendre le probleme, etant donne qu'aucun d'entre vous n'a insiste pour laisser la liste a l'interieur de l'objet. de plus, si on ne parle que de toi fabien garcia, tu as encore fait mieux que comprendre le probleme, puisque tu as carrement donne la solution.
conclusion : j'avais RAISON de penser que vous voyiez tres bien le probleme.
vous en avez deja suffisamment pour raisonner : un objet faisant partie d'une liste n'a pas a contenir la liste elle-meme.
Sauf s'il doit appeler une methode de la liste, ce qui dans ton cas ne peut etre evite que par un objet qui gererait la liste.
non, il y avait plusieurs solutions.
Alexandre
cette solution est equivalente a celle des listeners en java. or, ce n'est pas quelque chose de courant en c++.
1- quelle importance qu'elle soit courante ou non ? 2- moi je l'utilise assez souvent. Donc dans mes programmes elle est assez courante. 3- vu le nombre d'applis écrites en C++ je ne me lancerai pas dans ce genre d'affirmation.
cette solution est equivalente a celle des listeners en java. or, ce
n'est pas quelque chose de courant en c++.
1- quelle importance qu'elle soit courante ou non ?
2- moi je l'utilise assez souvent. Donc dans mes programmes elle est assez
courante.
3- vu le nombre d'applis écrites en C++ je ne me lancerai pas dans ce genre
d'affirmation.
cette solution est equivalente a celle des listeners en java. or, ce n'est pas quelque chose de courant en c++.
1- quelle importance qu'elle soit courante ou non ? 2- moi je l'utilise assez souvent. Donc dans mes programmes elle est assez courante. 3- vu le nombre d'applis écrites en C++ je ne me lancerai pas dans ce genre d'affirmation.
Alexandre
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.
des tas de livres moyens et de cours pas finis. Dès qu'on parle des patterns, la solution "observer" est courante. N'oublie pas que C++ est assez ancien, finalement...
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.
des tas de livres moyens et de cours pas finis. Dès qu'on parle des
patterns, la solution "observer" est courante.
N'oublie pas que C++ est assez ancien, finalement...
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.
des tas de livres moyens et de cours pas finis. Dès qu'on parle des patterns, la solution "observer" est courante. N'oublie pas que C++ est assez ancien, finalement...
Jean-Marc Bourguet
luc2 writes:
On 11 Jan 2005 14:08:47 +0100, Jean-Marc Bourguet wrote:
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.
Pourquoi pas ? C'est justement parce que c'est un objet qu'il peut s'inscrire et se désinscrire dans d'autres objets.
mais il ne DOIT PAS etre prevu pour s'inscrire et se desinscrire des autres objets. un objet coherent n'a pas a savoir par qui il est reference.
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.
Non quoi? Pour toi un objet qui s'incrit dans une liste et se désinscrit est plus compliqué qu'un objet ayant à gérer une liste d'observateurs en pratique constituée d'un seul membre n'observant qu'un seul évènement?
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.
C'est ton affirmation, je ne t'en ai toujours pas vu expliqué la raison.
mon objet est un thread. rien ne l'oblige a faire partie d'une liste ou il doit s'inscrire et se desinscrire. ses methodes et ses proprietes ne doivent donc contenir aucune information concernant une liste quelconque.
Dans ce cas tu sais où trouver une structure qui te conviens. Mais c'est à cause de tes préjugés que tu refuses d'en envisager d'autres, pas pour des raisons de conception.
class thread { thread[] liste; // faux
... }
C'est pas du C++, je ne comprends pas.
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.
Il faut toujours s'appuyer sur les principes, ils finiront bien pas craquer.
C'est quoi les "principes" ce cette "programmation objet" qui est universelle puisque pour toi tout problème a une solution qui les respectent (au fait c'est démontré où?)
Moi je ne connais qu'une méthode de conception qui a un nom qui s'approche de ça mais elle n'a pas prétention universelle et l'utiliser pour certains problèmes, c'est les contraindre aux forceps.
suppose que tu fasses une serie de boutons que l'on peut cliquer. chaque bouton est un objet. si on fait une liste de ces boutons dans le programme principal, chaque bouton ne DOIT PAS savoir qu'il est reference par une liste.
L'analogie entre boutons et threads me semblent fortement tirees par les cheveux.
cette analogie a seulement pour but de montrer que la liste ne doit pas etre dans l'objet. sur ce point de vue, le bouton et le thread sont pareils.
À nouveau, je considère une classe dans une application, pas une classe dans un univers abstrait. J'imagine très bien des threads dans des applications où la classe thread connaissant la liste est une bonne solution, comme d'autres où ce n'est pas une bonne solution. Pour les boutons ça me semble moins vraissemblable que ce soit une bonne solution que le bouton connaisse la liste.
En fait, j'ai souvent le cas où une classe maintient un registre statique de ses instances, accésible au moyen d'une fonction statique. Solution qui me semble convenir parfaitement ici.
alors tes programmes ne respectent pas les principes de la programmation objet.
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.
Et quel principe n'est pas respecté par une classe qui gère une liste de ses instances?
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
luc2 <luc2@nospam.invalid> writes:
On 11 Jan 2005 14:08:47 +0100, Jean-Marc Bourguet <jm@bourguet.org>
wrote:
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.
Pourquoi pas ? C'est justement parce que c'est un objet qu'il
peut s'inscrire et se désinscrire dans d'autres objets.
mais il ne DOIT PAS etre prevu pour s'inscrire et se desinscrire des
autres objets. un objet coherent n'a pas a savoir par qui il est
reference.
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.
Non quoi? Pour toi un objet qui s'incrit dans une liste et
se désinscrit est plus compliqué qu'un objet ayant à gérer
une liste d'observateurs en pratique constituée d'un seul
membre n'observant qu'un seul évènement?
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.
C'est ton affirmation, je ne t'en ai toujours pas vu
expliqué la raison.
mon objet est un thread. rien ne l'oblige a faire partie
d'une liste ou il doit s'inscrire et se desinscrire. ses
methodes et ses proprietes ne doivent donc contenir aucune
information concernant une liste quelconque.
Dans ce cas tu sais où trouver une structure qui te
conviens. Mais c'est à cause de tes préjugés que tu refuses
d'en envisager d'autres, pas pour des raisons de conception.
class thread
{
thread[] liste; // faux
...
}
C'est pas du C++, je ne comprends pas.
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.
Il faut toujours s'appuyer sur les principes, ils finiront
bien pas craquer.
C'est quoi les "principes" ce cette "programmation objet"
qui est universelle puisque pour toi tout problème a une
solution qui les respectent (au fait c'est démontré où?)
Moi je ne connais qu'une méthode de conception qui a un nom
qui s'approche de ça mais elle n'a pas prétention
universelle et l'utiliser pour certains problèmes, c'est les
contraindre aux forceps.
suppose que tu fasses une serie de boutons que l'on peut cliquer.
chaque bouton est un objet. si on fait une liste de ces boutons dans
le programme principal, chaque bouton ne DOIT PAS savoir qu'il est
reference par une liste.
L'analogie entre boutons et threads me semblent fortement tirees par
les cheveux.
cette analogie a seulement pour but de montrer que la liste ne doit
pas etre dans l'objet. sur ce point de vue, le bouton et le thread
sont pareils.
À nouveau, je considère une classe dans une application, pas
une classe dans un univers abstrait. J'imagine très bien
des threads dans des applications où la classe thread
connaissant la liste est une bonne solution, comme d'autres
où ce n'est pas une bonne solution. Pour les boutons ça me
semble moins vraissemblable que ce soit une bonne solution
que le bouton connaisse la liste.
En fait, j'ai souvent le cas où une classe maintient
un registre statique de ses instances, accésible au
moyen d'une fonction statique. Solution qui me semble
convenir parfaitement ici.
alors tes programmes ne respectent pas les principes de la
programmation objet.
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.
Et quel principe n'est pas respecté par une classe qui gère
une liste de ses instances?
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
On 11 Jan 2005 14:08:47 +0100, Jean-Marc Bourguet wrote:
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.
Pourquoi pas ? C'est justement parce que c'est un objet qu'il peut s'inscrire et se désinscrire dans d'autres objets.
mais il ne DOIT PAS etre prevu pour s'inscrire et se desinscrire des autres objets. un objet coherent n'a pas a savoir par qui il est reference.
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.
Non quoi? Pour toi un objet qui s'incrit dans une liste et se désinscrit est plus compliqué qu'un objet ayant à gérer une liste d'observateurs en pratique constituée d'un seul membre n'observant qu'un seul évènement?
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.
C'est ton affirmation, je ne t'en ai toujours pas vu expliqué la raison.
mon objet est un thread. rien ne l'oblige a faire partie d'une liste ou il doit s'inscrire et se desinscrire. ses methodes et ses proprietes ne doivent donc contenir aucune information concernant une liste quelconque.
Dans ce cas tu sais où trouver une structure qui te conviens. Mais c'est à cause de tes préjugés que tu refuses d'en envisager d'autres, pas pour des raisons de conception.
class thread { thread[] liste; // faux
... }
C'est pas du C++, je ne comprends pas.
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.
Il faut toujours s'appuyer sur les principes, ils finiront bien pas craquer.
C'est quoi les "principes" ce cette "programmation objet" qui est universelle puisque pour toi tout problème a une solution qui les respectent (au fait c'est démontré où?)
Moi je ne connais qu'une méthode de conception qui a un nom qui s'approche de ça mais elle n'a pas prétention universelle et l'utiliser pour certains problèmes, c'est les contraindre aux forceps.
suppose que tu fasses une serie de boutons que l'on peut cliquer. chaque bouton est un objet. si on fait une liste de ces boutons dans le programme principal, chaque bouton ne DOIT PAS savoir qu'il est reference par une liste.
L'analogie entre boutons et threads me semblent fortement tirees par les cheveux.
cette analogie a seulement pour but de montrer que la liste ne doit pas etre dans l'objet. sur ce point de vue, le bouton et le thread sont pareils.
À nouveau, je considère une classe dans une application, pas une classe dans un univers abstrait. J'imagine très bien des threads dans des applications où la classe thread connaissant la liste est une bonne solution, comme d'autres où ce n'est pas une bonne solution. Pour les boutons ça me semble moins vraissemblable que ce soit une bonne solution que le bouton connaisse la liste.
En fait, j'ai souvent le cas où une classe maintient un registre statique de ses instances, accésible au moyen d'une fonction statique. Solution qui me semble convenir parfaitement ici.
alors tes programmes ne respectent pas les principes de la programmation objet.
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.
Et quel principe n'est pas respecté par une classe qui gère une liste de ses instances?
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
luc2
On Tue, 11 Jan 2005 18:41:49 +0100, "Vincent Lascaux" wrote:
dis-moi quel pourcentage de programmes c++ contiennent des observeurs ?
Je dirais environ entre 67,81% et 83,11%
Pourquoi tu as besoin de savoir ca ?
parce que quand je discute avec quelqu'un de mauvaise foi, j'aime bien connaitre son taux de mauvaise foi afin savoir a quoi m'en tenir.
par exemple, quelqu'un de bonne foi repondrait :
java : 100% c++ : 0%
donc, pour connaitre le taux de mauvaise foi, je fais :
(100-67.81 + 83.11-0)/2 = 57.65
tu es donc de mauvaise foi a 57.65%.
On te propose un design pattern, c'est donc un truc qui est reconnu comme bon quelque soit le langage orienté objet si on est dans ses conditions d'utilisation. Point final.
ce n'est pas encore assez reconnu, puisque 0% des programmes en c++ ne les utilise.
On Tue, 11 Jan 2005 18:41:49 +0100, "Vincent Lascaux"
<nospam@nospam.org> wrote:
dis-moi quel pourcentage de programmes c++ contiennent des observeurs
?
Je dirais environ entre 67,81% et 83,11%
Pourquoi tu as besoin de savoir ca ?
parce que quand je discute avec quelqu'un de mauvaise foi, j'aime bien
connaitre son taux de mauvaise foi afin savoir a quoi m'en tenir.
par exemple, quelqu'un de bonne foi repondrait :
java : 100%
c++ : 0%
donc, pour connaitre le taux de mauvaise foi, je fais :
(100-67.81 + 83.11-0)/2 = 57.65
tu es donc de mauvaise foi a 57.65%.
On te propose un design pattern, c'est
donc un truc qui est reconnu comme bon quelque soit le langage orienté objet
si on est dans ses conditions d'utilisation. Point final.
ce n'est pas encore assez reconnu, puisque 0% des programmes en c++ ne
les utilise.
On Tue, 11 Jan 2005 18:41:49 +0100, "Vincent Lascaux" wrote:
dis-moi quel pourcentage de programmes c++ contiennent des observeurs ?
Je dirais environ entre 67,81% et 83,11%
Pourquoi tu as besoin de savoir ca ?
parce que quand je discute avec quelqu'un de mauvaise foi, j'aime bien connaitre son taux de mauvaise foi afin savoir a quoi m'en tenir.
par exemple, quelqu'un de bonne foi repondrait :
java : 100% c++ : 0%
donc, pour connaitre le taux de mauvaise foi, je fais :
(100-67.81 + 83.11-0)/2 = 57.65
tu es donc de mauvaise foi a 57.65%.
On te propose un design pattern, c'est donc un truc qui est reconnu comme bon quelque soit le langage orienté objet si on est dans ses conditions d'utilisation. Point final.
ce n'est pas encore assez reconnu, puisque 0% des programmes en c++ ne les utilise.
