Je suis un parachuté de l'assembleur (masm32) et pour des raisons
pratiques je me suis mis au C#.
J'ai donc pas mal de vilains automatismes alors que C# propose tout un
ensemble d'outil. Je vous fait grace d'un C/C du comment je fais pour
l'instant.
Voici ma question :
"Mon objet A lance selon ce que j'ai programmé des instances d'un objet
B. Est ce que .net fourni un outil qui me permet d'obtenir une liste de
toutes les instances de B ?"
Non, il faut l'expliciter en créant une référence de l'un sur l'autre. Simon.
"@(none)" <""k"@(none)"> a écrit dans le message de news:
Bonjour tout le monde.
Je suis un parachuté de l'assembleur (masm32) et pour des raisons pratiques je me suis mis au C#.
J'ai donc pas mal de vilains automatismes alors que C# propose tout un ensemble d'outil. Je vous fait grace d'un C/C du comment je fais pour l'instant.
Voici ma question :
"Mon objet A lance selon ce que j'ai programmé des instances d'un objet B. Est ce que .net fourni un outil qui me permet d'obtenir une liste de toutes les instances de B ?"
Merci d'avance.
~K~
Non, il faut l'expliciter en créant une référence de l'un sur l'autre.
Simon.
"@(none)" <""k"@(none)"> a écrit dans le message de news:
ecCfnHoJFHA.2956@TK2MSFTNGP12.phx.gbl...
Bonjour tout le monde.
Je suis un parachuté de l'assembleur (masm32) et pour des raisons
pratiques je me suis mis au C#.
J'ai donc pas mal de vilains automatismes alors que C# propose tout un
ensemble d'outil. Je vous fait grace d'un C/C du comment je fais pour
l'instant.
Voici ma question :
"Mon objet A lance selon ce que j'ai programmé des instances d'un objet B.
Est ce que .net fourni un outil qui me permet d'obtenir une liste de
toutes les instances de B ?"
Non, il faut l'expliciter en créant une référence de l'un sur l'autre. Simon.
"@(none)" <""k"@(none)"> a écrit dans le message de news:
Bonjour tout le monde.
Je suis un parachuté de l'assembleur (masm32) et pour des raisons pratiques je me suis mis au C#.
J'ai donc pas mal de vilains automatismes alors que C# propose tout un ensemble d'outil. Je vous fait grace d'un C/C du comment je fais pour l'instant.
Voici ma question :
"Mon objet A lance selon ce que j'ai programmé des instances d'un objet B. Est ce que .net fourni un outil qui me permet d'obtenir une liste de toutes les instances de B ?"
Merci d'avance.
~K~
Merci pour ta réponse =)
Je sais que le CLI (désolé si c pas le bon terme) à un compteur interne utilisé par son Garbage Collector. Je vais essayer de voir si il y a moyen d'obtenir l'information via ce moyen.
Simon Mourier [MS] a écrit :
Non, il faut l'expliciter en créant une référence de l'un sur l'autre. Simon.
Merci pour ta réponse =)
Je sais que le CLI (désolé si c pas le bon terme) à un compteur interne
utilisé par son Garbage Collector. Je vais essayer de voir si il y a
moyen d'obtenir l'information via ce moyen.
Simon Mourier [MS] a écrit :
Non, il faut l'expliciter en créant une référence de l'un sur l'autre.
Simon.
Je sais que le CLI (désolé si c pas le bon terme) à un compteur interne utilisé par son Garbage Collector. Je vais essayer de voir si il y a moyen d'obtenir l'information via ce moyen.
Simon Mourier [MS] a écrit :
Non, il faut l'expliciter en créant une référence de l'un sur l'autre. Simon.
Sylvain Lafontaine
Est-ce que c'est pour débugger ou profiler votre application? Parce qu'il y des profilers qui existent qui vont vous afficher la liste des objets et leur besoin en mémoire.
Si c'est pour utiliser à l'intérieur même de votre application, normalement, le design de vos classes devrait facilement s'occuper de ce problème si c'est requis.
S. L.
"@(none)" <""k"@(none)"> wrote in message news:
Merci pour ta réponse =)
Je sais que le CLI (désolé si c pas le bon terme) à un compteur interne utilisé par son Garbage Collector. Je vais essayer de voir si il y a moyen d'obtenir l'information via ce moyen.
Simon Mourier [MS] a écrit :
Non, il faut l'expliciter en créant une référence de l'un sur l'autre. Simon.
Est-ce que c'est pour débugger ou profiler votre application? Parce qu'il y
des profilers qui existent qui vont vous afficher la liste des objets et
leur besoin en mémoire.
Si c'est pour utiliser à l'intérieur même de votre application, normalement,
le design de vos classes devrait facilement s'occuper de ce problème si
c'est requis.
S. L.
"@(none)" <""k"@(none)"> wrote in message
news:u26D7LyJFHA.2428@TK2MSFTNGP10.phx.gbl...
Merci pour ta réponse =)
Je sais que le CLI (désolé si c pas le bon terme) à un compteur interne
utilisé par son Garbage Collector. Je vais essayer de voir si il y a moyen
d'obtenir l'information via ce moyen.
Simon Mourier [MS] a écrit :
Non, il faut l'expliciter en créant une référence de l'un sur l'autre.
Simon.
Est-ce que c'est pour débugger ou profiler votre application? Parce qu'il y des profilers qui existent qui vont vous afficher la liste des objets et leur besoin en mémoire.
Si c'est pour utiliser à l'intérieur même de votre application, normalement, le design de vos classes devrait facilement s'occuper de ce problème si c'est requis.
S. L.
"@(none)" <""k"@(none)"> wrote in message news:
Merci pour ta réponse =)
Je sais que le CLI (désolé si c pas le bon terme) à un compteur interne utilisé par son Garbage Collector. Je vais essayer de voir si il y a moyen d'obtenir l'information via ce moyen.
Simon Mourier [MS] a écrit :
Non, il faut l'expliciter en créant une référence de l'un sur l'autre. Simon.
Simon Mourier [MS]
Si c'est pour débugger, il y a des possibilités avec une extension nommé SOS.DLL ("son of strike"). voir ici:
et une autre encore plus puissante PSSCOR.DLL http://blogs.msdn.com/mvstanton/archive/2004/04/05/108023.aspx
Je ne sais pas si il y a ce que vous cherchez, mais on ne peut pas faire mieux :-)
Simon.
"@(none)" <""k"@(none)"> a écrit dans le message de news:
Merci pour ta réponse =)
Je sais que le CLI (désolé si c pas le bon terme) à un compteur interne utilisé par son Garbage Collector. Je vais essayer de voir si il y a moyen d'obtenir l'information via ce moyen.
Simon Mourier [MS] a écrit :
Non, il faut l'expliciter en créant une référence de l'un sur l'autre. Simon.
Si c'est pour débugger, il y a des possibilités avec une extension nommé
SOS.DLL ("son of strike").
voir ici:
et une autre encore plus puissante PSSCOR.DLL
http://blogs.msdn.com/mvstanton/archive/2004/04/05/108023.aspx
Je ne sais pas si il y a ce que vous cherchez, mais on ne peut pas faire
mieux :-)
Simon.
"@(none)" <""k"@(none)"> a écrit dans le message de news:
u26D7LyJFHA.2428@TK2MSFTNGP10.phx.gbl...
Merci pour ta réponse =)
Je sais que le CLI (désolé si c pas le bon terme) à un compteur interne
utilisé par son Garbage Collector. Je vais essayer de voir si il y a moyen
d'obtenir l'information via ce moyen.
Simon Mourier [MS] a écrit :
Non, il faut l'expliciter en créant une référence de l'un sur l'autre.
Simon.
et une autre encore plus puissante PSSCOR.DLL http://blogs.msdn.com/mvstanton/archive/2004/04/05/108023.aspx
Je ne sais pas si il y a ce que vous cherchez, mais on ne peut pas faire mieux :-)
Simon.
"@(none)" <""k"@(none)"> a écrit dans le message de news:
Merci pour ta réponse =)
Je sais que le CLI (désolé si c pas le bon terme) à un compteur interne utilisé par son Garbage Collector. Je vais essayer de voir si il y a moyen d'obtenir l'information via ce moyen.
Simon Mourier [MS] a écrit :
Non, il faut l'expliciter en créant une référence de l'un sur l'autre. Simon.
Bonjour =)
Jusqu'a présent j'utilise un ArrayList et a chaque instanciation de l'objet B j'utilise Add. Avant sa destruction l'objet de type B signale à ma classe principale A qu'il n'est plus disponible. Ce systeme fonctionne assez bien mais ne me semble pas élégant.
Le pourquoi je veux avoir une liste a jour de mes instances c'est que pour certaines conditions j'ai besoin d'appeller la méthode Afficher(string message) pour chacune de mes instances de B. Jusqu'a présent j'utilise un foreach.
Sans doute que je me pose trop de questions ^^.
Merci pour vos réponses ^^
~K~
Sylvain Lafontaine a écrit :
Est-ce que c'est pour débugger ou profiler votre application? Parce qu'il y des profilers qui existent qui vont vous afficher la liste des objets et leur besoin en mémoire.
Si c'est pour utiliser à l'intérieur même de votre application, normalement, le design de vos classes devrait facilement s'occuper de ce problème si c'est requis.
S. L.
Bonjour =)
Jusqu'a présent j'utilise un ArrayList et a chaque instanciation de
l'objet B j'utilise Add. Avant sa destruction l'objet de type B signale
à ma classe principale A qu'il n'est plus disponible. Ce systeme
fonctionne assez bien mais ne me semble pas élégant.
Le pourquoi je veux avoir une liste a jour de mes instances c'est que
pour certaines conditions j'ai besoin d'appeller la méthode
Afficher(string message) pour chacune de mes instances de B. Jusqu'a
présent j'utilise un foreach.
Sans doute que je me pose trop de questions ^^.
Merci pour vos réponses ^^
~K~
Sylvain Lafontaine a écrit :
Est-ce que c'est pour débugger ou profiler votre application? Parce qu'il y
des profilers qui existent qui vont vous afficher la liste des objets et
leur besoin en mémoire.
Si c'est pour utiliser à l'intérieur même de votre application, normalement,
le design de vos classes devrait facilement s'occuper de ce problème si
c'est requis.
Jusqu'a présent j'utilise un ArrayList et a chaque instanciation de l'objet B j'utilise Add. Avant sa destruction l'objet de type B signale à ma classe principale A qu'il n'est plus disponible. Ce systeme fonctionne assez bien mais ne me semble pas élégant.
Le pourquoi je veux avoir une liste a jour de mes instances c'est que pour certaines conditions j'ai besoin d'appeller la méthode Afficher(string message) pour chacune de mes instances de B. Jusqu'a présent j'utilise un foreach.
Sans doute que je me pose trop de questions ^^.
Merci pour vos réponses ^^
~K~
Sylvain Lafontaine a écrit :
Est-ce que c'est pour débugger ou profiler votre application? Parce qu'il y des profilers qui existent qui vont vous afficher la liste des objets et leur besoin en mémoire.
Si c'est pour utiliser à l'intérieur même de votre application, normalement, le design de vos classes devrait facilement s'occuper de ce problème si c'est requis.
S. L.
Faust
ce serait pas plus simple de passer par un système d'evenement? que la condition déclenche un evenement sur lequel les instances de classe B se seront branchées à leur création?
/_"none"_ a exprimé avec précision/ :
Bonjour =)
Jusqu'a présent j'utilise un ArrayList et a chaque instanciation de l'objet B j'utilise Add. Avant sa destruction l'objet de type B signale à ma classe principale A qu'il n'est plus disponible. Ce systeme fonctionne assez bien mais ne me semble pas élégant.
Le pourquoi je veux avoir une liste a jour de mes instances c'est que pour certaines conditions j'ai besoin d'appeller la méthode Afficher(string message) pour chacune de mes instances de B. Jusqu'a présent j'utilise un foreach.
Sans doute que je me pose trop de questions ^^.
Merci pour vos réponses ^^
~K~
Sylvain Lafontaine a écrit :
Est-ce que c'est pour débugger ou profiler votre application? Parce qu'il y des profilers qui existent qui vont vous afficher la liste des objets et leur besoin en mémoire.
Si c'est pour utiliser à l'intérieur même de votre application, normalement, le design de vos classes devrait facilement s'occuper de ce problème si c'est requis.
S. L.
-- */Teträm/* http://www.tetram.info
"Entre le cerveau et la main, le médiateur doit être le coeur" - Fritz Lang
ce serait pas plus simple de passer par un système d'evenement?
que la condition déclenche un evenement sur lequel les instances de
classe B se seront branchées à leur création?
/_"none"_ a exprimé avec précision/ :
Bonjour =)
Jusqu'a présent j'utilise un ArrayList et a chaque instanciation de l'objet
B j'utilise Add. Avant sa destruction l'objet de type B signale à ma classe
principale A qu'il n'est plus disponible. Ce systeme fonctionne assez bien
mais ne me semble pas élégant.
Le pourquoi je veux avoir une liste a jour de mes instances c'est que pour
certaines conditions j'ai besoin d'appeller la méthode Afficher(string
message) pour chacune de mes instances de B. Jusqu'a présent j'utilise un
foreach.
Sans doute que je me pose trop de questions ^^.
Merci pour vos réponses ^^
~K~
Sylvain Lafontaine a écrit :
Est-ce que c'est pour débugger ou profiler votre application? Parce qu'il
y des profilers qui existent qui vont vous afficher la liste des objets et
leur besoin en mémoire.
Si c'est pour utiliser à l'intérieur même de votre application,
normalement, le design de vos classes devrait facilement s'occuper de ce
problème si c'est requis.
S. L.
--
*/Teträm/*
http://www.tetram.info
"Entre le cerveau et la main, le médiateur doit être le coeur" - Fritz
Lang
ce serait pas plus simple de passer par un système d'evenement? que la condition déclenche un evenement sur lequel les instances de classe B se seront branchées à leur création?
/_"none"_ a exprimé avec précision/ :
Bonjour =)
Jusqu'a présent j'utilise un ArrayList et a chaque instanciation de l'objet B j'utilise Add. Avant sa destruction l'objet de type B signale à ma classe principale A qu'il n'est plus disponible. Ce systeme fonctionne assez bien mais ne me semble pas élégant.
Le pourquoi je veux avoir une liste a jour de mes instances c'est que pour certaines conditions j'ai besoin d'appeller la méthode Afficher(string message) pour chacune de mes instances de B. Jusqu'a présent j'utilise un foreach.
Sans doute que je me pose trop de questions ^^.
Merci pour vos réponses ^^
~K~
Sylvain Lafontaine a écrit :
Est-ce que c'est pour débugger ou profiler votre application? Parce qu'il y des profilers qui existent qui vont vous afficher la liste des objets et leur besoin en mémoire.
Si c'est pour utiliser à l'intérieur même de votre application, normalement, le design de vos classes devrait facilement s'occuper de ce problème si c'est requis.
S. L.
-- */Teträm/* http://www.tetram.info
"Entre le cerveau et la main, le médiateur doit être le coeur" - Fritz Lang
élo,
Je viens de faire une recherche breve sur les evenements. Si j'ai bien compris ca ne s'applique que pour les changements de fichier et/ou lorsqu'on utilise les evenements pour une interface graphique ?
Si c'est le cas cette méthode m'est inadaptée, mon projet est un serveur.
Faust a écrit :
ce serait pas plus simple de passer par un système d'evenement? que la condition déclenche un evenement sur lequel les instances de classe B se seront branchées à leur création?
élo,
Je viens de faire une recherche breve sur les evenements. Si j'ai bien
compris ca ne s'applique que pour les changements de fichier et/ou
lorsqu'on utilise les evenements pour une interface graphique ?
Si c'est le cas cette méthode m'est inadaptée, mon projet est un serveur.
Faust a écrit :
ce serait pas plus simple de passer par un système d'evenement?
que la condition déclenche un evenement sur lequel les instances de
classe B se seront branchées à leur création?
Je viens de faire une recherche breve sur les evenements. Si j'ai bien compris ca ne s'applique que pour les changements de fichier et/ou lorsqu'on utilise les evenements pour une interface graphique ?
Si c'est le cas cette méthode m'est inadaptée, mon projet est un serveur.
Faust a écrit :
ce serait pas plus simple de passer par un système d'evenement? que la condition déclenche un evenement sur lequel les instances de classe B se seront branchées à leur création?
Sylvain Lafontaine
Vous pouvez remplacer l'ArrayList par un HashList pour une meilleure performance en vitesse mais pour le reste; oui, à mon avis, vous vous posez sans doute trop de questions si votre programme fonctionne déjà sans problème.
D'autres solutions qui pourraient vous intéresser serait de n'accéder aux objects de type B qu'à travers la liste appartenant à A ou encore de cacher la liste directement dans la classe B.
Votre commentaire au sujet de la destruction de l'objet de type B m'apparaît suspect dans l'environnement managé de NET.
S. L.
"@(none)" <""k"@(none)"> wrote in message news:
Bonjour =)
Jusqu'a présent j'utilise un ArrayList et a chaque instanciation de l'objet B j'utilise Add. Avant sa destruction l'objet de type B signale à ma classe principale A qu'il n'est plus disponible. Ce systeme fonctionne assez bien mais ne me semble pas élégant.
Le pourquoi je veux avoir une liste a jour de mes instances c'est que pour certaines conditions j'ai besoin d'appeller la méthode Afficher(string message) pour chacune de mes instances de B. Jusqu'a présent j'utilise un foreach.
Sans doute que je me pose trop de questions ^^.
Merci pour vos réponses ^^
~K~
Sylvain Lafontaine a écrit :
Est-ce que c'est pour débugger ou profiler votre application? Parce qu'il y des profilers qui existent qui vont vous afficher la liste des objets et leur besoin en mémoire.
Si c'est pour utiliser à l'intérieur même de votre application, normalement, le design de vos classes devrait facilement s'occuper de ce problème si c'est requis.
S. L.
Vous pouvez remplacer l'ArrayList par un HashList pour une meilleure
performance en vitesse mais pour le reste; oui, à mon avis, vous vous posez
sans doute trop de questions si votre programme fonctionne déjà sans
problème.
D'autres solutions qui pourraient vous intéresser serait de n'accéder aux
objects de type B qu'à travers la liste appartenant à A ou encore de cacher
la liste directement dans la classe B.
Votre commentaire au sujet de la destruction de l'objet de type B m'apparaît
suspect dans l'environnement managé de NET.
S. L.
"@(none)" <""k"@(none)"> wrote in message
news:uP3tyF7JFHA.616@TK2MSFTNGP10.phx.gbl...
Bonjour =)
Jusqu'a présent j'utilise un ArrayList et a chaque instanciation de
l'objet B j'utilise Add. Avant sa destruction l'objet de type B signale à
ma classe principale A qu'il n'est plus disponible. Ce systeme fonctionne
assez bien mais ne me semble pas élégant.
Le pourquoi je veux avoir une liste a jour de mes instances c'est que pour
certaines conditions j'ai besoin d'appeller la méthode Afficher(string
message) pour chacune de mes instances de B. Jusqu'a présent j'utilise un
foreach.
Sans doute que je me pose trop de questions ^^.
Merci pour vos réponses ^^
~K~
Sylvain Lafontaine a écrit :
Est-ce que c'est pour débugger ou profiler votre application? Parce
qu'il y des profilers qui existent qui vont vous afficher la liste des
objets et leur besoin en mémoire.
Si c'est pour utiliser à l'intérieur même de votre application,
normalement, le design de vos classes devrait facilement s'occuper de ce
problème si c'est requis.
Vous pouvez remplacer l'ArrayList par un HashList pour une meilleure performance en vitesse mais pour le reste; oui, à mon avis, vous vous posez sans doute trop de questions si votre programme fonctionne déjà sans problème.
D'autres solutions qui pourraient vous intéresser serait de n'accéder aux objects de type B qu'à travers la liste appartenant à A ou encore de cacher la liste directement dans la classe B.
Votre commentaire au sujet de la destruction de l'objet de type B m'apparaît suspect dans l'environnement managé de NET.
S. L.
"@(none)" <""k"@(none)"> wrote in message news:
Bonjour =)
Jusqu'a présent j'utilise un ArrayList et a chaque instanciation de l'objet B j'utilise Add. Avant sa destruction l'objet de type B signale à ma classe principale A qu'il n'est plus disponible. Ce systeme fonctionne assez bien mais ne me semble pas élégant.
Le pourquoi je veux avoir une liste a jour de mes instances c'est que pour certaines conditions j'ai besoin d'appeller la méthode Afficher(string message) pour chacune de mes instances de B. Jusqu'a présent j'utilise un foreach.
Sans doute que je me pose trop de questions ^^.
Merci pour vos réponses ^^
~K~
Sylvain Lafontaine a écrit :
Est-ce que c'est pour débugger ou profiler votre application? Parce qu'il y des profilers qui existent qui vont vous afficher la liste des objets et leur besoin en mémoire.
Si c'est pour utiliser à l'intérieur même de votre application, normalement, le design de vos classes devrait facilement s'occuper de ce problème si c'est requis.
S. L.
J'ai été maladroit en m'exprimant. Disons que l'objet B sert un temps puis apres devient obsolete. Des qu'il est obsolete il se déclare comme tel et advienne que pourra pour lui. De toutes facon le port est libéré et pret a acceuillir un nouveau client.
Je vais jetter un oeil sur la HashList, merci du tuyau ^^
Sylvain Lafontaine a écrit :
Vous pouvez remplacer l'ArrayList par un HashList pour une meilleure performance en vitesse mais pour le reste; oui, à mon avis, vous vous posez sans doute trop de questions si votre programme fonctionne déjà sans problème.
D'autres solutions qui pourraient vous intéresser serait de n'accéder aux objects de type B qu'à travers la liste appartenant à A ou encore de cacher la liste directement dans la classe B.
Votre commentaire au sujet de la destruction de l'objet de type B m'apparaît suspect dans l'environnement managé de NET.
S. L.
J'ai été maladroit en m'exprimant. Disons que l'objet B sert un temps
puis apres devient obsolete. Des qu'il est obsolete il se déclare comme
tel et advienne que pourra pour lui. De toutes facon le port est libéré
et pret a acceuillir un nouveau client.
Je vais jetter un oeil sur la HashList, merci du tuyau ^^
Sylvain Lafontaine a écrit :
Vous pouvez remplacer l'ArrayList par un HashList pour une meilleure
performance en vitesse mais pour le reste; oui, à mon avis, vous vous posez
sans doute trop de questions si votre programme fonctionne déjà sans
problème.
D'autres solutions qui pourraient vous intéresser serait de n'accéder aux
objects de type B qu'à travers la liste appartenant à A ou encore de cacher
la liste directement dans la classe B.
Votre commentaire au sujet de la destruction de l'objet de type B m'apparaît
suspect dans l'environnement managé de NET.
J'ai été maladroit en m'exprimant. Disons que l'objet B sert un temps puis apres devient obsolete. Des qu'il est obsolete il se déclare comme tel et advienne que pourra pour lui. De toutes facon le port est libéré et pret a acceuillir un nouveau client.
Je vais jetter un oeil sur la HashList, merci du tuyau ^^
Sylvain Lafontaine a écrit :
Vous pouvez remplacer l'ArrayList par un HashList pour une meilleure performance en vitesse mais pour le reste; oui, à mon avis, vous vous posez sans doute trop de questions si votre programme fonctionne déjà sans problème.
D'autres solutions qui pourraient vous intéresser serait de n'accéder aux objects de type B qu'à travers la liste appartenant à A ou encore de cacher la liste directement dans la classe B.
Votre commentaire au sujet de la destruction de l'objet de type B m'apparaît suspect dans l'environnement managé de NET.
S. L.
Faust
dans ton code actuelement, tu veux un truc dans ce gout là:
if (Condition) foreach(B b in BChildren) B.AfficherMessage("blabla");
ce que je te propose c'est un truc dans ce gout là: if (Condition) DeclencherEvenement;
et tes instances de B auront un code qui leur ai propre qu'elles auront attaché à l'événement en question qui fera le AfficherMessage
outre que c'est comme ça que doit fonctionner la POO, ça te donnera plus de souplesse: une classe C pourra aussi s'attacher à l'evenement et faire autre chose que AfficherMessage sans que tu ai à modifier ta classe A
la gestion des evenements n'a absolument rien à voir avec les fichiers ou l'interface graphique: ça dépend uniquement de la façon dont sont écrites les classes. Mais, effectivement, la principale mise en application est de répondre aux evenement liés à l'interface graphique, mais ce n'est qu'une goutte d'eau dans un océan
/_"none"_ a exposé/ :
élo,
Je viens de faire une recherche breve sur les evenements. Si j'ai bien compris ca ne s'applique que pour les changements de fichier et/ou lorsqu'on utilise les evenements pour une interface graphique ?
Si c'est le cas cette méthode m'est inadaptée, mon projet est un serveur.
Faust a écrit :
ce serait pas plus simple de passer par un système d'evenement? que la condition déclenche un evenement sur lequel les instances de classe B se seront branchées à leur création?
-- */Teträm/* http://www.tetram.info
"On a toujours tort d'essayer d'avoir raison devant des gens qui ont toutes les bonnes raisons de croire qu'ils n'ont pas tort !" - Raymond Devos
dans ton code actuelement, tu veux un truc dans ce gout là:
if (Condition)
foreach(B b in BChildren)
B.AfficherMessage("blabla");
ce que je te propose c'est un truc dans ce gout là:
if (Condition)
DeclencherEvenement;
et tes instances de B auront un code qui leur ai propre qu'elles auront
attaché à l'événement en question qui fera le AfficherMessage
outre que c'est comme ça que doit fonctionner la POO, ça te donnera
plus de souplesse: une classe C pourra aussi s'attacher à l'evenement
et faire autre chose que AfficherMessage sans que tu ai à modifier ta
classe A
la gestion des evenements n'a absolument rien à voir avec les fichiers
ou l'interface graphique: ça dépend uniquement de la façon dont sont
écrites les classes. Mais, effectivement, la principale mise en
application est de répondre aux evenement liés à l'interface graphique,
mais ce n'est qu'une goutte d'eau dans un océan
/_"none"_ a exposé/ :
élo,
Je viens de faire une recherche breve sur les evenements. Si j'ai bien
compris ca ne s'applique que pour les changements de fichier et/ou lorsqu'on
utilise les evenements pour une interface graphique ?
Si c'est le cas cette méthode m'est inadaptée, mon projet est un serveur.
Faust a écrit :
ce serait pas plus simple de passer par un système d'evenement?
que la condition déclenche un evenement sur lequel les instances de classe
B se seront branchées à leur création?
--
*/Teträm/*
http://www.tetram.info
"On a toujours tort d'essayer d'avoir raison devant des gens qui ont
toutes les bonnes raisons de croire qu'ils n'ont pas tort !" - Raymond
Devos
dans ton code actuelement, tu veux un truc dans ce gout là:
if (Condition) foreach(B b in BChildren) B.AfficherMessage("blabla");
ce que je te propose c'est un truc dans ce gout là: if (Condition) DeclencherEvenement;
et tes instances de B auront un code qui leur ai propre qu'elles auront attaché à l'événement en question qui fera le AfficherMessage
outre que c'est comme ça que doit fonctionner la POO, ça te donnera plus de souplesse: une classe C pourra aussi s'attacher à l'evenement et faire autre chose que AfficherMessage sans que tu ai à modifier ta classe A
la gestion des evenements n'a absolument rien à voir avec les fichiers ou l'interface graphique: ça dépend uniquement de la façon dont sont écrites les classes. Mais, effectivement, la principale mise en application est de répondre aux evenement liés à l'interface graphique, mais ce n'est qu'une goutte d'eau dans un océan
/_"none"_ a exposé/ :
élo,
Je viens de faire une recherche breve sur les evenements. Si j'ai bien compris ca ne s'applique que pour les changements de fichier et/ou lorsqu'on utilise les evenements pour une interface graphique ?
Si c'est le cas cette méthode m'est inadaptée, mon projet est un serveur.
Faust a écrit :
ce serait pas plus simple de passer par un système d'evenement? que la condition déclenche un evenement sur lequel les instances de classe B se seront branchées à leur création?
-- */Teträm/* http://www.tetram.info
"On a toujours tort d'essayer d'avoir raison devant des gens qui ont toutes les bonnes raisons de croire qu'ils n'ont pas tort !" - Raymond Devos
