Faire un objet géré vraiment supprimables

Question

Contexte:

J'ai essayé de poser this question yesturday mais sans véritable conclusion, donc je pensais que je voudrais essayer de demander d'une manière différente que ce problème me cause un grand mal de tête .

Mon application est un outil de conception IHM intégré. Cela permet à l'utilisateur (qui est un développeur interne) de concevoir visuellement l'apparence de l'IHM intégrée et, ensuite, en cliquant sur un bouton, de générer le code C. La plupart de cela fonctionne maintenant.

L'un des principaux avantages de l'outil est qu'il permet à l'utilisateur de créer de nouveaux écrans (qui peuvent alors contenir des contrôles). Dans mon application, un «écran» est un objet. Quand un nouvel écran est ajouté, il est placé dans un List<Screen> qui est ensuite utilisé pour générer le code C.

L'une des propriétés de cet écran est le private Screen nextScreen qui est une référence à un autre objet d'écran qui indique quel écran afficher ensuite lorsque le bouton de navigation est enfoncé. Encore une fois tout cela fonctionne très bien.

Problème:

Cependant, lors de la lecture avec l'outil pour générer du code nous avons trouvé un problème. 2 écrans ont été créés, le premier écran ayant sa propriété nextScreen définie sur le 2ème. Un peu plus tard, il a été décidé que le deuxième écran était erroné, donc il a été supprimé et un nouvel écran a été créé. Cependant, ils ont oublié de définir la propriété nextScreen du premier écran sur ce nouvel écran, donc il faisait toujours référence à l'écran d'origine qui, visuellement, avait été supprimé.

Lorsque le code a été généré, le code C résultant n'a pas pu être compilé car le premier écran faisait référence à un écran qui, dans l'environnement C généré, n'existait pas.

Question:

Alors ma question est de savoir comment puis-je mettre en œuvre une meilleure façon de supprimer ce qui garantit que tout ce qui fait référence à un objet « supprimé » le sait et définit cette propriété sur null?

Pensées à ce jour:

1) J'ai essayé de créer la propriété « nextScreen » comme WeakReference qui fonctionne, mais cela signifie que je dois appeler manuellement le GC.Collect() chaque fois qu'un effacement est fait ... pas idéal de ma compréhension! (Mon exemple d'essayer ceci peut être trouvé dans le lien en haut de ce billet)

2) Je pourrais, après suppression, vérifier tous les objets pour une référence à celui qui est supprimé et le mettre à null. Cependant, ce que j'ai décrit ci-dessus n'est que l'un des nombreux objets composant l'IHM, dont la plupart ont une ou plusieurs références à d'autres objets. Donc, cela pourrait être lent et dans mon esprit ne semble pas juste.

3) Peut-être utiliser IDisposable ??? mais à ma connaissance, c'est pour le code non géré!

Toutes les idées ou les domaines pour que je puisse lire sur ce serait génial car je suis en train de me tirer les cheveux sur ce ... pas que j'ai beaucoup !!!

Answer 1

Je pense que vous pouvez utiliser modèle ObjectPool pour créer et supprimer des objets et certains Wrapper là-dessus est des objets, de contrôler leur livetime

Answer 2

L'un des impératifs de conception fondamentaux du GC est s'il y a un moyen par lequel code peut rencontrer une référence à un objet, l'objet continuera à exister. Il n'y a aucun moyen de "supprimer" un objet de sorte que les références à celui-ci deviendront invalides. Il y a, cependant, deux choses que vous pouvez faire:

1. Demandez à votre classe inclure un champ qui indique si elle a été invalidée et que le code qui reçoit ou suit une référence à une instance de classe, vérifiez que champ Assurez-vous que l'instance est toujours valide. Si le code définit ce champ dans une instance, toutes les références ne seront plus des références à une instance valide, mais deviendront (par définition) des références à une instance invalide.

2. Si vous créez un WeakReference à un objet, la propriété Target de cette WeakReference deviendra null lorsque le GC détecte aucune référence non faible à la cible existe (si une référence à une cible non nul est copié une autre variable, cette variable gardera la cible en vie même si la référence faible était la seule chose dans l'univers avec une référence à la cible). Le fait de forcer un cycle complet de collecte des ordures annulera généralement immédiatement toute référence faible à des objets qui ne sont référencés nulle part, mais représenterait un abus du système GC. Mettre en œuvre une routine "trouver tous les objets utilisés" qui compte combien de fois il a été exécuté, et avoir un champ dans chaque instance de classe dans laquelle cette routine va stocker son compteur. Tout objet qui devrait être considéré comme "utilisé" contiendra la valeur du compteur de routine "trouver tous les objets utilisés" qui a été tenu la dernière fois qu'il a été exécuté. C'est un peu comme ce que le GC fait avec les objets qu'il connaît, mais si vous le faites vous-même, vous pouvez décider quelles formes de référence devraient justifier qu'un objet soit "utilisé".

Answer 3

Vous pouvez créer une nouvelle classe générique appelée Deletable<T> pour envelopper vos objets. Il fonctionnerait comme Nullable<T> en ce qu'il contient une propriété de type T qui contient la valeur d'origine. Il aurait besoin d'une propriété en lecture seule boolIsDeleted qui indique si la valeur encapsulée a été supprimée et une méthode Delete qui annule la valeur encapsulée et définit l'indicateur IsDeleted.

Tout ce qui utilise les objets Screen passerait à Deletable<Screen>. Lorsqu'un écran est supprimé, appelez Delete sur le wrapper. Tout code qui se soucie si un écran est supprimé peut simplement vérifier scr.IsDeleted avant d'utiliser scr.Value.

Cela permettra à la récupération de place pour nettoyer tous les objets volumineux, tout en laissant une petite valeur "flag" à sa place que vous pouvez utiliser pour vérifier si l'objet réel a été supprimé.