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.
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...
Ici, par exemple, on pourrait avoir une ABC "ThreadObserver"
avec des fonction membres virtuelles pures "Notify_started()"
et "Notify_terminated()" ;
chaque "Thread" comporte soit un pointeur sur "ThreadObserver"
(relation à cardinalité 0..1), soit un conteneur de pointeurs
(délation 0..n).
La classe "ThreadList" dérive de "ThreadObserver" et implémente
les fonctions mentionnées ci-dessus. Ainsi, un "Thread" n'a pas
à savoir qu'il appartient à une liste où il faut s'inscrire ou
désinscrire, il connaît uniquement l'interface définie par
"ThreadObserver".
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.
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...
Ici, par exemple, on pourrait avoir une ABC "ThreadObserver"
avec des fonction membres virtuelles pures "Notify_started()"
et "Notify_terminated()" ;
chaque "Thread" comporte soit un pointeur sur "ThreadObserver"
(relation à cardinalité 0..1), soit un conteneur de pointeurs
(délation 0..n).
La classe "ThreadList" dérive de "ThreadObserver" et implémente
les fonctions mentionnées ci-dessus. Ainsi, un "Thread" n'a pas
à savoir qu'il appartient à une liste où il faut s'inscrire ou
désinscrire, il connaît uniquement l'interface définie par
"ThreadObserver".
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.
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...
Ici, par exemple, on pourrait avoir une ABC "ThreadObserver"
avec des fonction membres virtuelles pures "Notify_started()"
et "Notify_terminated()" ;
chaque "Thread" comporte soit un pointeur sur "ThreadObserver"
(relation à cardinalité 0..1), soit un conteneur de pointeurs
(délation 0..n).
La classe "ThreadList" dérive de "ThreadObserver" et implémente
les fonctions mentionnées ci-dessus. Ainsi, un "Thread" n'a pas
à savoir qu'il appartient à une liste où il faut s'inscrire ou
désinscrire, il connaît uniquement l'interface définie par
"ThreadObserver".
On Tue, 11 Jan 2005 15:21:57 +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++.
On Tue, 11 Jan 2005 15:21:57 +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++.
On Tue, 11 Jan 2005 15:21:57 +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++.
"luc2" a écrit dans le message de news:On 11 Jan 2005 14:08:47 +0100, Jean-Marc BourguetAh? 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 d ogmes
religieux.
"luc2" <luc2@nospam.invalid> a écrit dans le message de news:
psp7u0pka4r0ukkdrbjrvnub7i2d38upon@4ax.com...
On 11 Jan 2005 14:08:47 +0100, Jean-Marc Bourguet <jm@bourguet.org>
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 d ogmes
religieux.
"luc2" a écrit dans le message de news:On 11 Jan 2005 14:08:47 +0100, Jean-Marc BourguetAh? 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 d ogmes
religieux.
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++.
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++.
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++.
ce que tu viens d'ecrire confirme ce que je pensais : tu es loin de la
programmation objet, et surtout, loin de l'esprit de conception.
Je pense que tu n'as pas compris le sens d'une des réponse de Jean-Marc.
La POO ne fait pas l'objet d'une idéologie sacrée sur ce groupe. Si tu
souhaites une discussion politique ou idéologique, il y en a qui sont plus
approprié que celui-ci qui a plutôt une vocation technique.
la question que j'ai pose est une question de CONCEPTION. je peux donc
CONCEVOIR mes classes comme je le veux. si j'ai besoin que le thread
puisse accepter un listener, alors je le CONCOIS comme tel.
Non. Tu ne peux pas nécessairement les concevoir comme tu veux car il se
peut qu'elles soient amenées à collaborer avec un cadre pré-existant, que ce
soit des bibliothèques ou frameworks tierces ou une api spécifique imposée
par ton système d'exploitation.
les listeners sont couramment utilises en java. c'est donc une
solution propre et non-marginale. de plus, elle respecte les
principes de la programmation objet.
Le fait d'utiliser les listeners n'a rien à voir avec le
langage. C'était courant en C++ avant même que le Java existait,
et courant en Smalltalk avant que le C++ ait vu le jour.
Celà devient dépendant du langage dès que c'est le langage qui définit l'api
avec le système d'exploitation.
je crois que tu confonds "etre courant" et "exister". les listeners
existent en c++, mais ils ne sont pas courants. demande a un
programmeur de c++ s'il sait ce qu'est un listener, il ne saura pas,
il n'en aura jamais utilise, tandis qu'en java, il y a cent chances
sur cent qu'il sache ce que c'est.
Parce que les listeners font partie de l'api de java et ne sont pas dans ces
cas précis un simple choix de conception de la part du programmeur.
en java, il est evident que les listeners sont courants : il y en a
partout dans l'api du java. on est donc obliges de s'en servir.
Donc on est d'accord que c'est quelque chose qui a à voir avec le langage,
contrairement à ce que tu affirmes quelques paragraphes au dessus.
le fait est la : les listeners SONT plus frequents en java. donc, ca
ne me derange pas d'utiliser cette solution en java. les listeners NE
SONT PAS frequents en c++, donc, ca me derange d'utiliser cette
solution en c++.
Ne sont pas fréquents en C++ ? C'est dans quel verset de ta bible ?
les listeners ne sont pas courants en c++.
Ça dépend du domaine d'application. Ils sont très courants où
ils conviennent.
je ne suis pas en train de me restreindre a un domaine quelconque. je
dis qu'en GENERAL (c'est-a-dire a partir d'une vision GLOBALE de tous
les domaines), les listeners ne sont pas courants en c++.
Il n'y a rien de général. tout dépend du type d'application que tu crées.
S'il y a moins *en général* de listeners en C++ qu'en Java (ce qui reste à
démontrer), c'est que les applications cibles en ont moins besoin *en
général*.
maintenant que vous avez eu un exemple de ce que j'attendais
comme solution, ce sera de la rigolade pour vous d'y repondre.
Mais si tu sais ce que tu veux comme solution, pourquoi la
question ?
parce que ma solution concerne le java, pas le c++.
Et pourquoi une solution adoptée dans un langage ferait qu'elle ne peut pas
l'être dans un autre ?
je n'ai pas demande une solution quelconque. j'ai demande une solution
propre et non-marginale. si les listeners ne sont pas courants en c++,
alors la solution des listeners est marginale en c++.
Comme il a été dit, les listeners ne sont pas "marginaux" en C++.
ce que tu viens d'ecrire confirme ce que je pensais : tu es loin de la
programmation objet, et surtout, loin de l'esprit de conception.
Je pense que tu n'as pas compris le sens d'une des réponse de Jean-Marc.
La POO ne fait pas l'objet d'une idéologie sacrée sur ce groupe. Si tu
souhaites une discussion politique ou idéologique, il y en a qui sont plus
approprié que celui-ci qui a plutôt une vocation technique.
la question que j'ai pose est une question de CONCEPTION. je peux donc
CONCEVOIR mes classes comme je le veux. si j'ai besoin que le thread
puisse accepter un listener, alors je le CONCOIS comme tel.
Non. Tu ne peux pas nécessairement les concevoir comme tu veux car il se
peut qu'elles soient amenées à collaborer avec un cadre pré-existant, que ce
soit des bibliothèques ou frameworks tierces ou une api spécifique imposée
par ton système d'exploitation.
les listeners sont couramment utilises en java. c'est donc une
solution propre et non-marginale. de plus, elle respecte les
principes de la programmation objet.
Le fait d'utiliser les listeners n'a rien à voir avec le
langage. C'était courant en C++ avant même que le Java existait,
et courant en Smalltalk avant que le C++ ait vu le jour.
Celà devient dépendant du langage dès que c'est le langage qui définit l'api
avec le système d'exploitation.
je crois que tu confonds "etre courant" et "exister". les listeners
existent en c++, mais ils ne sont pas courants. demande a un
programmeur de c++ s'il sait ce qu'est un listener, il ne saura pas,
il n'en aura jamais utilise, tandis qu'en java, il y a cent chances
sur cent qu'il sache ce que c'est.
Parce que les listeners font partie de l'api de java et ne sont pas dans ces
cas précis un simple choix de conception de la part du programmeur.
en java, il est evident que les listeners sont courants : il y en a
partout dans l'api du java. on est donc obliges de s'en servir.
Donc on est d'accord que c'est quelque chose qui a à voir avec le langage,
contrairement à ce que tu affirmes quelques paragraphes au dessus.
le fait est la : les listeners SONT plus frequents en java. donc, ca
ne me derange pas d'utiliser cette solution en java. les listeners NE
SONT PAS frequents en c++, donc, ca me derange d'utiliser cette
solution en c++.
Ne sont pas fréquents en C++ ? C'est dans quel verset de ta bible ?
les listeners ne sont pas courants en c++.
Ça dépend du domaine d'application. Ils sont très courants où
ils conviennent.
je ne suis pas en train de me restreindre a un domaine quelconque. je
dis qu'en GENERAL (c'est-a-dire a partir d'une vision GLOBALE de tous
les domaines), les listeners ne sont pas courants en c++.
Il n'y a rien de général. tout dépend du type d'application que tu crées.
S'il y a moins *en général* de listeners en C++ qu'en Java (ce qui reste à
démontrer), c'est que les applications cibles en ont moins besoin *en
général*.
maintenant que vous avez eu un exemple de ce que j'attendais
comme solution, ce sera de la rigolade pour vous d'y repondre.
Mais si tu sais ce que tu veux comme solution, pourquoi la
question ?
parce que ma solution concerne le java, pas le c++.
Et pourquoi une solution adoptée dans un langage ferait qu'elle ne peut pas
l'être dans un autre ?
je n'ai pas demande une solution quelconque. j'ai demande une solution
propre et non-marginale. si les listeners ne sont pas courants en c++,
alors la solution des listeners est marginale en c++.
Comme il a été dit, les listeners ne sont pas "marginaux" en C++.
ce que tu viens d'ecrire confirme ce que je pensais : tu es loin de la
programmation objet, et surtout, loin de l'esprit de conception.
Je pense que tu n'as pas compris le sens d'une des réponse de Jean-Marc.
La POO ne fait pas l'objet d'une idéologie sacrée sur ce groupe. Si tu
souhaites une discussion politique ou idéologique, il y en a qui sont plus
approprié que celui-ci qui a plutôt une vocation technique.
la question que j'ai pose est une question de CONCEPTION. je peux donc
CONCEVOIR mes classes comme je le veux. si j'ai besoin que le thread
puisse accepter un listener, alors je le CONCOIS comme tel.
Non. Tu ne peux pas nécessairement les concevoir comme tu veux car il se
peut qu'elles soient amenées à collaborer avec un cadre pré-existant, que ce
soit des bibliothèques ou frameworks tierces ou une api spécifique imposée
par ton système d'exploitation.
les listeners sont couramment utilises en java. c'est donc une
solution propre et non-marginale. de plus, elle respecte les
principes de la programmation objet.
Le fait d'utiliser les listeners n'a rien à voir avec le
langage. C'était courant en C++ avant même que le Java existait,
et courant en Smalltalk avant que le C++ ait vu le jour.
Celà devient dépendant du langage dès que c'est le langage qui définit l'api
avec le système d'exploitation.
je crois que tu confonds "etre courant" et "exister". les listeners
existent en c++, mais ils ne sont pas courants. demande a un
programmeur de c++ s'il sait ce qu'est un listener, il ne saura pas,
il n'en aura jamais utilise, tandis qu'en java, il y a cent chances
sur cent qu'il sache ce que c'est.
Parce que les listeners font partie de l'api de java et ne sont pas dans ces
cas précis un simple choix de conception de la part du programmeur.
en java, il est evident que les listeners sont courants : il y en a
partout dans l'api du java. on est donc obliges de s'en servir.
Donc on est d'accord que c'est quelque chose qui a à voir avec le langage,
contrairement à ce que tu affirmes quelques paragraphes au dessus.
le fait est la : les listeners SONT plus frequents en java. donc, ca
ne me derange pas d'utiliser cette solution en java. les listeners NE
SONT PAS frequents en c++, donc, ca me derange d'utiliser cette
solution en c++.
Ne sont pas fréquents en C++ ? C'est dans quel verset de ta bible ?
les listeners ne sont pas courants en c++.
Ça dépend du domaine d'application. Ils sont très courants où
ils conviennent.
je ne suis pas en train de me restreindre a un domaine quelconque. je
dis qu'en GENERAL (c'est-a-dire a partir d'une vision GLOBALE de tous
les domaines), les listeners ne sont pas courants en c++.
Il n'y a rien de général. tout dépend du type d'application que tu crées.
S'il y a moins *en général* de listeners en C++ qu'en Java (ce qui reste à
démontrer), c'est que les applications cibles en ont moins besoin *en
général*.
maintenant que vous avez eu un exemple de ce que j'attendais
comme solution, ce sera de la rigolade pour vous d'y repondre.
Mais si tu sais ce que tu veux comme solution, pourquoi la
question ?
parce que ma solution concerne le java, pas le c++.
Et pourquoi une solution adoptée dans un langage ferait qu'elle ne peut pas
l'être dans un autre ?
je n'ai pas demande une solution quelconque. j'ai demande une solution
propre et non-marginale. si les listeners ne sont pas courants en c++,
alors la solution des listeners est marginale en c++.
Comme il a été dit, les listeners ne sont pas "marginaux" 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
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
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
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++.
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++.
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++.
Mais en pratique, un objet est rarement "cohérent" *par lui-même*.
c'est qu'il est mal concu.
Non. L'objectif dans un système objet n'est pas d'avoir des objets autonomes
mais de les faire communiquer entre eux.
La
finalité d'un objet, c'est assez souvent de collaborer avec d'autres
objets.
D'une manière ou d'une autre, le listener doit bien être tenu informé des
objets qu'il écoute. Soit il les créera ou les détruira de lui-même,
auquel
cas l'objet lui-même n'aura pas besoin de s'inscrire et se désinscrire,
soit
la création de l'objet se fait via une api qui echape au listener, auquel
cas ce sera à l'objet écouté de s'enregistrer/désenregistrer.
je ne vois pas ou tu veux en venir. quelle est la bonne solution ?
quelle est la mauvaise ? c'est le listener qui doit desinscrire
l'objet ? ou c'est l'objet lui-meme ?
La bonne ou mauvaise solution dépendra de contraintes spécifiques au cas par
cas. L'objectif finale est que la procédure
d'enregistrement/désenregistrement soit fiable, si possible automatique. Il
n'y a pas une façon unique d'atteindre ce but en C++. Il se peut aussi que
différentes solutions se valent ou aient chacunes leurs avantages et
inconvénients au cas par cas (pourrait-on réellement parler de choix de
design dans le cas contraire ?).
La cohérence, ça consiste avant tout à trouver une solution qui fournisse
la
fonctionnalité attendue en fonction des différentes contraintes de
l'environnement.
c'est une autre coherence dont tu parles la. moi, je parlais de la
coherence par rapport a la programmation objet.
Et quels sont ces critères de cohérence selon toi ?
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.
Mais en pratique, un objet est rarement "cohérent" *par lui-même*.
c'est qu'il est mal concu.
Non. L'objectif dans un système objet n'est pas d'avoir des objets autonomes
mais de les faire communiquer entre eux.
La
finalité d'un objet, c'est assez souvent de collaborer avec d'autres
objets.
D'une manière ou d'une autre, le listener doit bien être tenu informé des
objets qu'il écoute. Soit il les créera ou les détruira de lui-même,
auquel
cas l'objet lui-même n'aura pas besoin de s'inscrire et se désinscrire,
soit
la création de l'objet se fait via une api qui echape au listener, auquel
cas ce sera à l'objet écouté de s'enregistrer/désenregistrer.
je ne vois pas ou tu veux en venir. quelle est la bonne solution ?
quelle est la mauvaise ? c'est le listener qui doit desinscrire
l'objet ? ou c'est l'objet lui-meme ?
La bonne ou mauvaise solution dépendra de contraintes spécifiques au cas par
cas. L'objectif finale est que la procédure
d'enregistrement/désenregistrement soit fiable, si possible automatique. Il
n'y a pas une façon unique d'atteindre ce but en C++. Il se peut aussi que
différentes solutions se valent ou aient chacunes leurs avantages et
inconvénients au cas par cas (pourrait-on réellement parler de choix de
design dans le cas contraire ?).
La cohérence, ça consiste avant tout à trouver une solution qui fournisse
la
fonctionnalité attendue en fonction des différentes contraintes de
l'environnement.
c'est une autre coherence dont tu parles la. moi, je parlais de la
coherence par rapport a la programmation objet.
Et quels sont ces critères de cohérence selon toi ?
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.
Mais en pratique, un objet est rarement "cohérent" *par lui-même*.
c'est qu'il est mal concu.
Non. L'objectif dans un système objet n'est pas d'avoir des objets autonomes
mais de les faire communiquer entre eux.
La
finalité d'un objet, c'est assez souvent de collaborer avec d'autres
objets.
D'une manière ou d'une autre, le listener doit bien être tenu informé des
objets qu'il écoute. Soit il les créera ou les détruira de lui-même,
auquel
cas l'objet lui-même n'aura pas besoin de s'inscrire et se désinscrire,
soit
la création de l'objet se fait via une api qui echape au listener, auquel
cas ce sera à l'objet écouté de s'enregistrer/désenregistrer.
je ne vois pas ou tu veux en venir. quelle est la bonne solution ?
quelle est la mauvaise ? c'est le listener qui doit desinscrire
l'objet ? ou c'est l'objet lui-meme ?
La bonne ou mauvaise solution dépendra de contraintes spécifiques au cas par
cas. L'objectif finale est que la procédure
d'enregistrement/désenregistrement soit fiable, si possible automatique. Il
n'y a pas une façon unique d'atteindre ce but en C++. Il se peut aussi que
différentes solutions se valent ou aient chacunes leurs avantages et
inconvénients au cas par cas (pourrait-on réellement parler de choix de
design dans le cas contraire ?).
La cohérence, ça consiste avant tout à trouver une solution qui fournisse
la
fonctionnalité attendue en fonction des différentes contraintes de
l'environnement.
c'est une autre coherence dont tu parles la. moi, je parlais de la
coherence par rapport a la programmation objet.
Et quels sont ces critères de cohérence selon toi ?
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.
ce n'est toujours pas propre comme solution. il est naturel de vouloir
mettre la liste a jour immediatement.et
de tout facon comment peux tu etre sur que pendant ta demande un thread
ne se termine pas. un thread c'est paralelle par definition.
cela n'est pas le centre du probleme.
ce n'est toujours pas propre comme solution. il est naturel de vouloir
mettre la liste a jour immediatement.
et
de tout facon comment peux tu etre sur que pendant ta demande un thread
ne se termine pas. un thread c'est paralelle par definition.
cela n'est pas le centre du probleme.
ce n'est toujours pas propre comme solution. il est naturel de vouloir
mettre la liste a jour immediatement.et
de tout facon comment peux tu etre sur que pendant ta demande un thread
ne se termine pas. un thread c'est paralelle par definition.
cela n'est pas le centre du probleme.
cette solution n'est pas propre. en effet, la liste ne sera pas
toujours a jour. elle ne le sera que periodiquement.
pourquoi?
avant de lui demandé quelque chose tu la mets a jour ("manuellement")
et
de tout facon comment peux tu etre sur que pendant ta demande un thread
ne se termine pas. un thread c'est paralelle par definition.
cette solution n'est pas propre. en effet, la liste ne sera pas
toujours a jour. elle ne le sera que periodiquement.
pourquoi?
avant de lui demandé quelque chose tu la mets a jour ("manuellement")
et
de tout facon comment peux tu etre sur que pendant ta demande un thread
ne se termine pas. un thread c'est paralelle par definition.
cette solution n'est pas propre. en effet, la liste ne sera pas
toujours a jour. elle ne le sera que periodiquement.
pourquoi?
avant de lui demandé quelque chose tu la mets a jour ("manuellement")
et
de tout facon comment peux tu etre sur que pendant ta demande un thread
ne se termine pas. un thread c'est paralelle par definition.
