Discussion :

[peter27x]

Hello,

quand vous vous retrouvez, sous Delphi, à avoir une appli dans laquelle vivent des dizaines d'objets, et que vous avez une information en entrée devant être acheminée à un ou plusieurs objets bien particuliers, préférez-vous:

1) faire un envoi de message massif qui sera lu par tous les enfants de l'appli (la fonction existe), du moins tous les enfants ayant cet événement déclaré (WM_xxx), soit ici tous les objets.

2) faire une boucle dans l'appli, boucle qui parcourt tous les objets, et qui, selon certains de leurs attributs, active ou pas une de leurs fonctions.

Je pencherais naturellement vers la première (message) car l'appli principale est libérée dès l'envoi du message. Son inconvénient est qu'ensuite tous les objets entreront dans la fonction correspondant au message (WM-xxx), d'où peut-être plus grosse utilisation de processus système.
Et à priori pour mon appli le + important est quand même qu'elle soit le plus libre possible.

Mais vos avis d'experts vont surement m'apporter tout plein de lumières.

Merci.

[peter27x]

Bon, ça a pas l'air d'inspirer grand monde...

Je verrai "in testu" !

[Aka Guymelef]

Ben disons que ça parait étrange de parler de communication par message entre des objets d'une même application.
Je ne dis pas que ce n'est pas faisable mais généralement c'est laissé pour la communication de l'interface graphique ou bien inter-programme éventuellement.

Généralement quand on a besoin que des objets communiquent soit on créé des liens entre eux => objet contenant une liste d'autre objet, soit on fait par évènement => un objet publie un évènement, un autre y répond.

[peter27x]

Ben disons que ça parait étrange de parler de communication par message entre des objets d'une même application.
Je ne dis pas que ce n'est pas faisable mais généralement c'est laissé pour la communication de l'interface graphique ou bien inter-programme éventuellement.

Généralement quand on a besoin que des objets communiquent soit on créé des liens entre eux => objet contenant une liste d'autre objet, soit on fait par évènement => un objet publie un évènement, un autre y répond.

Que mes objets communiquent entre eux, c'est prévu, et de la manière que tu évoques : lien vers d'autres objets...

Ma question est différente : c'est mon appli qui devra porter à la connaissance un message de, disons, 20 objets par exemple, sachant que seuls par exemple 4 d'entre eux seront réellement concernés, et là deux possibilités (je répète mon post initial !) :
- soit envoi d'un message général, les non concernés passeront leur chemin après lecture de celui ci, les autres enchaînement certains traitements internes...
- soit mon appli trie elle même les objets concernés (via un de leurs attribut), et actionne une de leur méthode le cas échéant.

Et donc comme déjà dit, je privilégie la première, car l'appli est "libérée" juste après l'envoi du message, alors que la seconde implique une boucle et des lancements de méthodes à effectuer PAR l'appli...

[Aka Guymelef]

L'ennui avec les messages c'est que ce n'est pas forcement instantané or si tu as besoin que ton traitement le soi...

Enfin à mon sens pour bien répondre à la question il nous faut plus de détail sur qui doit communiquer à qui, dans quelle fréquence et avec quelles contraintes.

[peter27x]

L'ennui avec les messages c'est que ce n'est pas forcement instantané or si tu as besoin que ton traitement le soi...

Enfin à mon sens pour bien répondre à la question il nous faut plus de détail sur qui doit communiquer à qui, dans quelle fréquence et avec quelles contraintes.

L'appli est à faire.

Mais sinon comme déjà dis, je clos la file et je verrai "in visu" (ou terme approchant...

[Aka Guymelef]

"In situ" je pense que c'est le terme que tu cherches

[peter27x]

"In situ" je pense que c'est le terme que tu cherches

Merci je connais la forme originale de cette expression latine !

Je faisais exprès d'employer un terme informatisé dans la première version que je viens d'aller relire "in testu" c'est à celle ci que je faisais référence dans mon précédent mail

[sjrd]

D'un point de modularité, la première me semble la meilleure. Car c'est bien chaque objet qui est le plus capable de décider si un message le concerne ou non.

En revanche, je n'utiliserais pas des messages, du moins pas avec SendMessage, mais un méthode adaptée, ou avec TObject.Dispatch (ou avec une méthode adaptée qui wrappe un appel à Dispatch).

[peter27x]

D'un point de modularité, la première me semble la meilleure. Car c'est bien chaque objet qui est le plus capable de décider si un message le concerne ou non.

En revanche, je n'utiliserais pas des messages, du moins pas avec SendMessage, mais un méthode adaptée, ou avec TObject.Dispatch (ou avec une méthode adaptée qui wrappe un appel à Dispatch).

Merci pour l'info sur dispatch.

Je pensais à utiliser postMessage() à la base en fait... mais je n'ai pas encore pu mettre tout ça en pratique.

Là j'en suis à faire du reverseEngeneering d'une grosse appli existante mais qui n'est pas aussi aboutie que celle que je compte mettre en place... c'est du boulot.