2 votes

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

En remaniant certaines classes C#, je suis tombé sur des classes qui implémentent IDisposable.

Sans réfléchir, j'ai créé des fichiers de classe partiels pour chaque classe qui implémente l'interface IDisposable.

Par exemple) Pour Stamper.cs -> Stamper.cs + Stamper.Dispose.cs où Stamper.cs contient la logique réelle de l'estampillage et Stamper.Dispose.cs qui contient une logique d'élimination

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

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

Quand j'ai regardé le code, Stamper.cs semble maintenant beaucoup plus propre et lisible (maintenant environ 52 lignes au lieu de 100 lignes où environ 50 lignes étaient simplement un code de nettoyage et de disposition)

Est-ce que je vais trop loin avec ça ?

*EDIT : Merci à tous pour vos avis - J'ai décidé de réunir deux fichiers en un seul. Le problème auquel j'étais confronté était que j'oubliais de mettre à jour l'implémentation d'IDisposable après avoir mis à jour la logique actuelle.

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

0voto

Allen Rice Points 8899

C'est une question un peu étrange, car elle n'a d'impact que sur le développeur, ce qui fait qu'elle dépend entièrement des préférences personnelles. Je ne peux que vous dire ce que je préférerais, c'est-à-dire que je le ferais si une quantité importante de logique se trouvait dans la partie disposal.

0voto

STW Points 15326

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.

Quant aux classes partielles, je ne les utilise que si une classe est très grande et peut être classée en groupes de méthodes. Cacher le code du concepteur est aussi très bien.

0voto

supercat Points 25534

Je favoriserais l'utilisation d'une classe partielle lorsque, et seulement lorsque, le code en question est généré par ordinateur. Si vous avez de nombreuses 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 sources et les fichiers générés comme du code intermédiaire de type objet. Il semblerait tout à fait approprié d'extraire le code généré par les modèles dans des classes partielles.

En vb.net, une telle approche pourrait être intéressante pour permettre la déclaration, l'initialisation et le nettoyage des champs, qui seraient traités ensemble et en toute sécurité dans un objet IDisposable. Une quantité modérée de code passe-partout est nécessaire, mais les déclarations de champs sont ensuite assez 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 le nouveau DisposableThingie à une liste détenue par la classe. La routine Dispose de la classe disposerait alors de tous les éléments de la liste.

Malheureusement, il n'y a pas de moyen propre de faire quelque chose de similaire en C#, puisque les initialisateurs de champs ne peuvent pas utiliser l'objet sur le point d'être construit (en vb.net, les initialisateurs de champs sont exécutés après la construction de l'objet de base).

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X