Comment forcer la class d'instanciation à appeler une méthode d'une class instanciée

Bonjour.

Imaginons une class A qui dispose d'une méthode subA.

Cette class A est instanciée dans la Class B.

Comme forcer l'appel à la méthode subA dans cette Class B (peut importe quand) ?

En fait, il s'agit ici de forcer la class B à "s'engager" à utiliser la méthode subA de l'instance de la class A.

Exemple : tu peux utiliser mon téléphone si tu t'engages à raccrocher une fois la conversation terminée.
(je sais c'est c.. comme exemple).

Existe-t'il quelque chose (un atribut par exemple) pour ce genre de choses ?

EDIT : pour expliciter un peu plus...
En préparant un article sur le Hook souris, je me suis rendu compte que ma class gérant le Hook exigeait une prise d'abonnement à l'évènement "activité de la souris" et une levée de l'abonnement dans toutes les classes qui l'utilisent.
Comme le Hook est créé à la premiére prise d'abonnement et libéré à la derniére levée d'abonnement, si une instance de classe ne lève pas l'abonnement, le Hook peut rester actif pour rien.
L'idée etait donc de n'accepter dans la prise d'abonnement que les classes qui implémentent IComponent (et donc IDisposable) et lèvent (ou pas d'ailleurs) l'event Disposed. Sur cet event, la class gérant le Hook désabonne l'instance de classe disposée.
Comme généralement, le Hook est utilisé par un control ou un component (sans surchage de Dispose), ça le fait.

Mais le top du top serait de pouvoir forcer l'utilisation du désabonnement (à un moment donné mais sans être sûr qu'il sera effectué à l'exécution ... évidemment).

Cdt.

je n'ai as les idées très claires ce matin, mais, si tu héritais d'une classe abstraite, qui se chargerait entre autre de

• instancier ta classe A dans une méthode que tu surchargeras dans ta classe B

• se désabonner (lorsque tu as fini ton traitement) dans une méthode que tu surchargeras aussi dans ta classe B

Puis dans ta classe héritant de la classe abstraite, tu n'oublies pas d'appeller la méthode de la base, et tu fais ton traitement ensuite, idem lorsque tu veux finir ton traitement

Oliv.

Bonjour.

Merci pour ta proposition.

Cependant, je ne peux procéder ainsi car, par exemple, dans le cas de mon Hook, il peut trés bien être utilisé par une class héritant de control, de component ou d'autre chose. Comme le multiple héritage n'existe pas ... ça tombe à l'eau.

Mais aprés réflection, je pense que jamais on ne pourra être sûr que la méthode est appelée, et donc il faut plutôt chercher la solution la moins pire.
Je penche donc vers une interface avec un event "je veux me désabonner". Libre à la classe implémentant cette interface de le lever ou pas, mais le fait de forcer l'utilisation de l'interface, mettra au moins en évidence l'existence de cette évènement.
Sinon, je vais tester aussi l'utilisation d'un delegate, chaque objet voulant s'abonner devant fournir l'adresse de la procédure de désabonnement...

Je reste ouvert à toute suggestion.

EDIT : bon bon bon, aprés moulte recherches, j'arrive à la conclusion que dans tous les cas, il restera une faille.


Cdt.

en fait non pas forcément
il ya un moyen de palier a ce probleme.

il n'est pas totalement parfait mais accroira néanmoins la robustesse de ton système.

pour cela, tout d'abord il faut un peu modifier le systeme d'appels et d'abonnements.
Pour qu'une classe s'abonne tu lui fait implémenter une interface qui possède toutes les méthodes d'évenement auxquelles la classe peut souscrire dans ton gestionnaire de Hook.

Ensuite lorsqu'elle s'abonne elle appelle la méthode d'abonnement dans laquelle elle fournie seulement sa référence d'instance... implantant une interface dédiée, tu sauras forcément quel membre invoquer et comment.

Tu fourni toujours une méthode de désabonnement, mais qui n'est plus obligatoire, mais préférable.

Ensuite c'est là que ca change... c'est dans ta facon de stocker les abonnements.
Tu n'utilise pas le style d'abonnement "event" fourni par le C# mais tu gere ta propre collecton d'abonnements (collection d'instances implantant l'interface)
et pour etre plus précis tu ne fait pas référence directement à l'instance d'interface dans ta collection, mais tu fait référence à une classe représentant des "références faibles".
WeakReference si mes souvenirs sont bon

l'interet ? très simple, si tu référence normallement ta classe, l'arbre de ses références ne sera pas vide, donc elle ne sera jamais supprimée par le GC, pire elle ne sera meme jamais disposed.
si tu utilise les weakreference, la référence que tu conserver échappe à l'arbre de recouvrement des références donc si la référence n'est plus usité ailleurs dans le programme elle pourra alors etre "détruite". Si tel est le cas, c'est quelle a été disposée et si tu dispose d'une telle référence c'est que la classe ne se désabonne pas.

Ensuite tu peux tester l'état de l'instance au moment ou tu effectue l'envoie d'evenements ou tu peux lancer un thread de facon cyclique qui va faire le ménage et désabonner automatiquement les classes/références qui auraient été supprimées, décomptant ton compteur d'utilisation.

Cependant ne crie pas victoire trop vite. Normallement ces références faibles sont surtout utilisées pour mettre en évidence des Caches. Cela ne te permettra pas de distinguer une instance active d'un instance aurait été disposed, mais qui serait en attente de nettoyage par le GC, car en effet, ce système t'indique juste si l'instance est toujours en mémoire ou si le GC l'a nettoyé, pas si elle est en attente de nettoyage.
Attention aussi, le fait de demander la référence associée peut la faire sortir de la liste des classes en attente de nettoyage...
Mais c'est "moins pire" que de ne pas avoir de désabonnement car on ne peut jamais faire "confiance" au code appelant.