dans une classe qui implémente Idisposable , quand est-il raisonnable de vérifier si l'objet a été disposé et jette objetdisposedException si elle a? Dans toutes les méthodes et propriétés publiques (sauf disposer )? Parfois? Jamais?
5 Réponses :
Vous devez mettre en œuvre ce chèque uniquement dans les méthodes qui ne fonctionnent pas sur un objet disposé.
Par exemple:
Si votre classe ferme les connexions de base de données ou les poignées de fichier dans Disposez , toutes les méthodes nécessitant des connexions de base de données ou des poignées de fichier doivent vérifier si l'instance est déjà exposée.
Comme vous le dites, je voudrais mettre en œuvre cette vérification dans toutes les méthodes et propriétés publiques, sauf disposer et isdisposé. Ceci est le Modèle standard pour empêcher un développeur d'utiliser votre type dans l'impression erronée qu'il est toujours valide.
Une certaine discrétion serait en ordre. Que diriez-vous de membres isdisposés et / ou isopen?
Je voudrais jeter sur Isopen. Pour isdisposed, je ne voudrais pas jeter.
La seule chose qui est vraiment spécifiée est que et toute méthode qui nécessite les ressources gérées (ONU) devrait lancer.
qui part, dans mon esprit, seulement quelques cas contestables:
Il devient plus difficile lorsque la classe se combine (sans rapport) fonctionne comme un flux et une collection. Nous ne devrions tout simplement pas faire ça. annulation publique joint () doit pas jeter quoi que ce soit.
L'utilisation d'un objet disposé est une erreur de programmation que vous souhaitez trouver aussi vite que possible.
Plus vous vérifiez les endroits où vous le vérifiez plus vite, vous trouverez l'erreur.
Vous devez certainement vérifier l'endroit où un objet disposé provoquera un autre type d'exception (I.e. Null Pointer) pour ne pas confondre l'utilisateur.
Dans d'autres endroits, cela dépend de l'application si cela vaut la peine d'effort.
Si un objet prend en charge ISDisposé, cette méthode elle-même ne devrait jamais jeter; Il serait approprié que de nombreuses autres méthodes de lancer si ISDisposed revient vrai, mais l'exception doit être générée par ces méthodes plutôt que par ISDisposed. On pourrait avoir une méthode utilitaire affectée à ce qui lancerait si un objet est disposé, mais un tel comportement serait attendu d'une méthode avec ce nom.
Sinon, je suggérerais qu'il existe de nombreux cas où il est utile d'avoir un objet d'objet tiennent un objet Idisposable et de pouvoir disposer de l'objet intérieur tout en maintenant un état utile. Par exemple, un objet dont la fonction est de montrer et de maintenir une boîte de dialogue sans faille pour obtenir des informations à partir d'un utilisateur peut utilement à conserver une copie du contenu des champs même après la fermeture de la zone. Un tel objet devrait fournir une méthode "close" qui disposera d'objets jetables internes mais de maintenir un état utile. Bien qu'il puisse également disposer d'une méthode d'expiration qui ferait appeler la fermeture, mais également définir un drapeau "Nolongervalid" qui causerait des propriétés sur le terrain, je ne pense pas que cela ajoute vraiment une valeur.
Je vais accorder que de nombreux cas où un objet peut contenir un état utile après avoir été éliminé indique une classe qui devrait peut-être être divisée. Par exemple, la classe de police doit peut-être être divisée en une classe Fontinfo non jetable (contenant une description d'une police, mais pas une poignée GDI) et une classe IDisposable ReadyFont (héritage de fontinfo et encapsulant un objet de police GDI). Les routines qui utilisent une police pourraient vérifier si l'objet à qui elles a été donné était un Fontinfo ou un ReadyFont; Dans le premier cas, ils pourraient créer une police GDI, l'utiliser et la libérer; Dans ce dernier cas, ils pourraient utiliser l'objet de police GDI de ReadyFont et le relâcher. Le créateur d'un ReadyFont serait alors responsable de l'assurer son nettoyage.
tel qu'il est, je ne sais pas si le système essaiera d'utiliser l'objet GDI associé à la propriété de polices de contrôle lors du contrôle, mais je sais que cela ne squa pas si la police est disposée (même si Il est disposé avant de l'attribuer à la propriété de polices!). Les commandes sont certainement capables de créer de nouvelles polices GDI si nécessaire; Je ne sais pas s'ils créent toujours une nouvelle police GDI ou si elles ne le font que si l'ancien a été disposé. L'ancien comportement semblerait être plus performant, mais sauf si codé ne pouvait poser des problèmes si un fil essayait de disposer d'une police pendant qu'un autre fil l'utilisait.
Ne voulez-vous pas simplement envelopper l'objet dans une déclaration en utilisant? Ainsi, l'objet étant disposé lorsqu'il n'est pas nécessaire automatiquement?
@Darren: Vous supposez ensuite qu'un utilisateur de mon type jetable se comporte correctement. Rarement le cas! :-)
@Lazarus: GC a rien à faire avec
Idisposable /Dispose . Le GC recueille des objets non référencés; Cela ne dispose rien.Ok Nice One .. Donc, si quelque chose ne va pas dans le dispositif, alors comment vous allez savoir si l'objet est disposé ou non, est-ce exactement ce que vous recherchez?
@Lazarus: Je pense que vous comprenez mal de ce qui élimine les moyens. Disposer n'est rien de plus qu'une méthode dans une interface d'un outil de classe. Cela n'a vraiment rien à voir avec le GC ou le CLR.
Tout - je ne sais pas où se trouvait mon cerveau ce matin ... évidemment pas assez de café. Je me sens très penaud! :)
@Johann Gerell: N'oubliez pas d'accepter une réponse si cela vous a aidé.