J'ai besoin d'un moyen de suivre les cas de diverses classes, sans que ces classes ne connaissent aucune connaissance qu'ils sont suivies. Essentiellement, j'ai une usine de classe qui crée des instances et les associe à un autre fil. Une fois que ce fil se termine et décharge l'instance, je dois être informé de cela afin que je puisse faire le comptage et la sortie de mon usine de classe lorsque toutes les instances ont disparu.
Le défi est que je ne peux modifier aucune des classes, je vais en chargement, car je ne contrôle pas leur code source.
Suivi des instances que je crée est simple, je peux simplement les mettre dans une sorte de collection que je les crée. Suivi de leur destruction me causent des problèmes. Si je pouvais modifier le code source, j'ajouterais un événement à chaque classe et lorsque je crée une instance, je vous connecterais à l'événement et que je l'utilise comme ma notification. Mais je ne peux pas faire ça.
Donc, la question est la suivante: y a-t-il un moyen sournois de surveiller une instance d'objet et de détecter quand il est détruit?
4 Réponses :
Que diriez-vous de contrôler la destruction de l'objet:
public void Destroy(T obj)
{
if (obj == null)
throw new ArgumentNullException("obj");
if (!_living.Contains(obj))
throw new ArgumentException("Where did this obj come from?");
using (obj as IDisposable)
{
}
_living.Remove(obj); // List?
}
Alors, quels appels détruisent ()? N'oubliez pas que je ne peux pas contrôler les types que je me charge (en fait, ils sont chargés de manière dynamique d'un dossier et je ne sais pas à l'avance ce que je vais y trouver).
Puisque vous créez les objets, il semble que vous puissiez revenir un décorateur au lieu de l'instance réelle.
En utilisant le motif de décorateur , vous pouvez "envelopper" l'objet renvoyé dans vous-même, API décorée. La décoration pourrait fournir une implémentation isisposable qui a fourni votre notification de destruction.
C'est sympa. Vous pouvez utiliser la réflexion pour générer le décorateur. Ce serait important si la classe est massive.
C'est très intéressant, je vais suivre cela. Merci.
Il n'y a pas de moyen d'obtenir une notification active, mais vous pouvez conserver un edit: J'aime mieux la réponse de Reed que le mien! affaiblissement sur les objets et vérifier périodiquement s'il est décédé.
+1 C'est drôle - je pensais la même chose exacte, jusqu'à ce que je lisais la partie où il a dit qu'il contrôla la construction des objets;)
Cela ressemble en fait que cela pourrait être la solution la plus utilisable dans ma situation, je vais essayer cela.
J'aime mieux que les roseaux, car cela signifie que les clients de ces types n'ont pas besoin de savoir sur un type de décorateur spécial
Si vous détenez une liste des références aux instances que vous créez, elles ne recevront pas de déchets collectés et ne seront donc jamais détruits ...
au lieu de cela, vous pouvez créer un référentiel qui détient une liste de GUID et créer une nouvelle GUID pour chaque instance, puis ajoutez-le à une liste à la place - quelque chose comme un dépositaire usine. De cette manière, vous n'avez pas de problème de référence pour la collecte des ordures à mesure que les GUID sont des structures plutôt que des types de référence. Vous pouvez ensuite hériter de chaque classe pour créer un type qui peut notifier sur Détruire. Je suppose que comme vous ne pouvez pas modifier le code des classes d'origine, vous ne pouvez pas également modifier les consommateurs de ces classes. Par conséquent, quelque chose comme le modèle de décorateur (via une interface) est éteint car les types ne seraient pas compatibles.
Exemple très simplifié: