Dois-je séparer la logique Dispose dans un fichier de classe partiel?

Question

Lors de la refonte de certaines classes C#, j'ai rencontré des classes implémentant IDisposable. Sans réfléchir, j'ai créé des fichiers de classe partiels pour chaque classe qui implémente l'interface IDisposable.

Eg) Pour Stamper.cs -> Stamper.cs + Stamper.Dispose.cs où Stamper.cs contient une logique réelle pour l'estampage et Stamper.Dispose.cs qui contient la logique de disposer

// Stamper.cs 
public partial class Stamper 
{ 
// actual logic 
} 

// Stamper.Dispose.cs 
public partial class Stamper: IDisposable 
{ 
// Implement IDisposable 
} 

Quand je regardais le code, Stamper.cs semble maintenant beaucoup plus propre et lisible (maintenant environ 52 lignes au lieu de 100 lignes où environ 50 lignes était simplement un code de disposer de nettoyage)

Vais-je trop loin w c'est ça?

* EDIT: Merci pour votre avis - J'ai décidé de mettre deux fichiers en un. Le problème que j'avais rencontré était que j'oublie réellement de mettre à jour l'implémentation d'IDisposable après la mise à jour de la logique actuelle.

De plus, il n'y avait pas beaucoup de problèmes de navigation entre les méthodes dans le code source. La première raison semble plus qu'une raison suffisante pour s'en tenir à une solution de fichier dans mon cas particulier.

Answer 1

Il semble à peu près aussi arbitraire que de créer une classe partielle pour la logique du constructeur. Maintenant, je dois regarder deux fichiers pour grock cette classe. Les classes partielles ne valent vraiment le coup que pour le design ...

Answer 2

Oui, trop loin. Qu'est-ce qui ne va pas avec juste coller un #Region autour du code et le plier de sorte que vous ne pouvez pas le voir?

Answer 3

Si votre procédure de nettoyage est lourde, c'est acceptable, mais pas idéale.

Cela peut être une bonne habitude pour la plaque de la chaudière comme les événements exposés, les méthodes de sérialisation lourdes et dans votre gestion de mémoire de cas.

I préférer classes partielles que les contours (#region). Si vous devez utiliser une classe partielle ou un code pour rendre votre code lisible, c'est généralement un signe que le code doit être modifié. Déchirer la classe appart et seulement en dernier recours utiliser la classe partielle (ou région) si le code est absolument nécessaire pour l'entretien de cette classe.

Dans votre cas, vous pouvez utiliser une classe qui enveloppe finement la ressource non gérée et expose une seule Dispose. Ensuite, dans l'autre classe, utilisez l'objet géré et Disposez-le sans logique.

Si votre classe n'est qu'une enveloppe mince, je dirais que votre méthode est trop lourde car tout le point de la classe est de disposer d'une ressource non gérée.

Answer 4

Je préférerais voir la logique d'élimination dans le même fichier que les ressources qui justifient l'implémentation d'IDisposable. Bien qu'il y ait un élément de subjectivité, je dirais que c'est trop loin

Answer 5

Je pense que votre solution est malsaine. Les classes partielles ne doivent généralement être utilisées que pour séparer le code du développeur du code du générateur. Les régions font généralement un meilleur travail d'ajout de structure à votre code.

Answer 6

Sorte de question étrange car elle n'a d'impact que sur le développeur, ce qui en fait un choix personnel. Je peux seulement vous dire ce que je préférerais et ce serait que je le ferais si une part importante de la logique était dans la disposition.

Answer 7

Personnellement, j'essaie de garder ma logique d'instanciation/initialisation et ma logique de nettoyage/élimination côte-à-côte, c'est un bon rappel. En ce qui concerne les classes partielles, la seule fois où je les utilise est si une classe est très grande et peut être catégorisée en groupes de méthodes. Cacher le code du concepteur est super aussi.

Answer 8

Je préférerais utiliser une classe partielle quand, et seulement quand, le code en question a été généré par ordinateur. Si vous avez plusieurs classes qui partagent un code similaire (qui, pour diverses raisons, doit être répété, plutôt que d'être extrait dans sa propre classe), il peut être utile d'avoir quelques modèles et un programme pour générer le code basé sur ces modèles. Dans ce scénario, les modèles seraient considérés comme des fichiers source, puis générés en tant que code objet-ish intermédiaire. Il semblerait tout à fait approprié de sortir le code généré par un template dans des classes partielles.

Dans vb.net, une telle approche pourrait être utile pour permettre la déclaration de champ, l'initialisation et le nettoyage pour être manipulés en toute sécurité au sein d'un objet IDisposable. Une quantité modérée de code standard est requise, mais les déclarations sur le terrain après cela sont plutôt propres. Par exemple:

 
' Assuming Option Implicit on: 
Dim MyThingie = RegDisposable(New DisposableThingie) 
' If Implicit wasn't on: 
Dim MyThingie As DisposableThingie = RegDisposable(New DisposableThingie) 

RegDisposable serait un membre de la classe qui ajouterait à la nouvelle DisposableThingie une liste détenue par la classe. La routine "Dispose" de la classe devrait alors Disposer tous les éléments de la liste. Malheureusement, il n'y a pas de méthode propre pour faire quelque chose de similaire en C#, car les initialiseurs de champs ne peuvent pas utiliser l'objet sur le point de se construire (dans vb.net, les initialiseurs de champ sont exécutés après la construction de l'objet de base).