Classes partielles en C#

la génération de Code a été la force motrice derrière les classes partielles. Le besoin vient d'avoir une classe générée par le code qui est en constante évolution, mais permettre aux développeurs de fournir du code personnalisé dans le cadre de la classe qui ne sera pas supplanté chaque fois que des changements sont faits qui forcent la classe à être régénérée.

prendre WinForms ou Typed-DataSets par exemple (ou n'importe quel concepteur pour cette matière). Chaque fois que vous faites un changement au concepteur il sérialise le correspondant code dans un fichier. Disons que vous devez fournir quelques méthodes supplémentaires dont le générateur ne sait rien. Si vous l'avez ajouté au fichier généré vos modifications seraient perdues la prochaine fois qu'il a été généré.

un projet sur lequel je travaille actuellement utilise la génération de code pour tous les DAL, BLL, et entités commerciales. Cependant, le générateur ne reçoit que 75% des informations. La partie restante doit être codée à la main (logique d'affaires personnalisée par exemple). Je peux supposons que chaque classe BLL ait une méthode SelectAll, donc c'est facile à générer. Cependant, mon client BLL a également besoin d'avoir une méthode SelectAllByLocation. Je ne peux pas mettre ça dans mon générateur parce que ce n'est pas générique pour toutes les classes de BLL. Par conséquent, je génère toutes mes classes en tant que classes partielles, et puis dans un fichier séparé Je définit mes méthodes personnalisées. Maintenant, plus tard, quand ma structure change, ou que j'ai besoin de régénérer mon BLL pour une raison quelconque, mon code personnalisé ne sera pas effacé.

j'utilise des classes partielles comme un moyen de séparer les différents sous-éléments des contrôles personnalisés que j'écris. De plus, lorsqu'il est utilisé avec un logiciel de création d'entités, il permet à des produits comme LLBLGen de créer des versions générées de classes, ainsi qu'une version personnalisée éditée par l'utilisateur, qui ne sera pas remplacée si les entités ont besoin d'être régénérées.

j'utilise souvent des classes partielles de donner à chaque classe imbriquée son propre fichier. Il y a eu des architectures sur lesquelles j'ai travaillé où la plupart de l'implémentation n'était requise que par une seule classe et nous avons donc intégré ces classes dans cette classe. Il était logique de garder les fichiers plus faciles à maintenir en utilisant la capacité de classe partielle et en divisant chacun dans son propre fichier.

nous les avons également utilisés pour grouper des stock overrides ou la dissimulation d'un stock ensemble de propriétés. Des choses comme ça. C'est une façon pratique de mélanger dans un changement de stock (il suffit de copier le fichier et de changer le nom partiel de la classe à la classe cible - aussi longtemps que la classe cible est rendue partielle aussi, bien sûr).

une autre utilisation possible pour les classes partielles serait de tirer parti des méthodes partielles pour faire disparaître sélectivement les méthodes en utilisant la compilation conditionnelle - ce serait parfait pour le code de diagnostic en mode de débogage ou les scénarios de tests unitaires spécialisés.

Vous pouvez déclarer une partielle méthode comme une méthode abstraite, puis dans l'autre classe partielle, lorsque vous tapez le mot-clé "partielle", vous pouvez profiter de l'Intellisense pour créer la mise en œuvre de cette méthode.

si vous entourez une partie avec des instructions de construction conditionnelle, alors vous pouvez facilement couper le code de débogage ou de test. Dans l'exemple ci - dessous, en mode DEBUG, la méthode LogSomethingDebugOnly est appelée, mais dans la compilation de la version, c'est comme si la méthode n'existait pas du tout-une bonne façon de garder le code de diagnostic éloigné du code de production sans un tas de branchements ou de multiples blocs de compilation conditionnelle.

// Main Part
public partial class Class1
{
    private partial void LogSomethingDebugOnly();

    public void SomeMethod()
    {
        LogSomethingDebugOnly();
        // do the real work
    }
}

// Debug Part - probably in a different file
public partial class Class1
{

    #if DEBUG

    private partial void LogSomethingDebugOnly()
    {
        // Do the logging or diagnostic work
    }

    #endif
}

LINQ à SQL fait bon usage de classes partielles pour étendre le code généré par le concepteur. Je pense que vous trouverez généralement ce modèle de classes partielles utilisées par le concepteur-code créé.

je trouve les cours partiels extrêmement utiles. Habituellement, ils sont utilisés pour être en mesure d'étendre les classes autogénérées. Je les ai utilisés dans un projet avec des tests d'unités lourdes. Mes classes UT avaient des dépendances complexes et il n'était pas très pratique de séparer le code entre plusieurs classes.Bien sûr, il est préférable d'utiliser l'héritage\composition, mais dans certains cas, des classes partielles peuvent être rallye utile.

comme mentionné plus tôt, je pense aussi que c'est une odeur de code.

si une classe est si grande qu'elle doit être divisée en plusieurs fichiers, cela signifie qu'elle enfreint le principe de responsabilité unique et fait trop de choses. La grande classe pourrait être décomposée en classes plus petites qui coopèrent ensemble.

si vous devez utiliser des classes partielles ou des régions pour organiser le code, considérez si elles devraient être dans leurs propres classes. Augmente la lisibilité et vous aurez plus de code réutilisé.

peut-être est-il trop tard, mais s'il vous plaît laissez-moi ajouter mes 2 cents aussi:

*.Lorsque vous travaillez sur de grands projets, répartir une classe sur des fichiers séparés permet à plusieurs programmeurs de travailler simultanément.

*.Vous pouvez facilement écrire votre code (pour une fonctionnalité étendue) VS.NET classe générée. Cela vous permettra d'écrire le code de votre propre besoin sans toucher au code généré par le système

là où je suis, nous avons un programme qui traite les fichiers entrants des clients. Il est configuré de façon à ce que le code de chaque client soit dans son propre projet de bibliothèque de classe, qui sait comment gérer quel que soit le format que le client choisit d'utiliser.

le code principal utilise les bibliothèques en définissant une interface assez étendue qu'une classe de la bibliothèque doit implémenter (probablement quelques interfaces distinctes, mais il est trop tard pour la changer maintenant). Parfois, cela implique beaucoup plus de code dans la même classe que ce qu'on pense normalement prudent. Les classes partielles nous permettent de les séparer un peu.

sur UserControls qui sont relativement compliqués, j'ai mis le traitement d'événement dans un fichier et la peinture et les propriétés dans un autre fichier. Les classes partielles fonctionnent très bien pour cela, habituellement ces parties de la classe sont relativement indépendantes et il est agréable d'être en mesure d'éditer la peinture et la manipulation d'événement côte à côte.

j'ai travaillé sur un projet il y a quelques années où nous avions une classe d'ensemble de données dactylographiées qui avait une tonne de code en elle: méthodes dans les DataTables, méthodes dans les TableAdapters, déclarations des instances de TableAdapter, vous l'appelez. C'était un point central massif du projet sur lequel tout le monde devait travailler souvent, et il y avait beaucoup de contestations de contrôle à la source sur le fichier de code de classe partiel.

donc j'ai divisé le fichier de code en fix ou six fichiers de classe partielle, groupés par fonction, pour que nous puissions travailler sur des pièces plus petites et ne pas avoir à verrouiller le dossier entier à chaque fois que nous devions changer quelque chose.

(bien sûr, nous aurions aussi pu résoudre le problème en n'utilisant pas un système de contrôle à la source exclusivement verrouillé, mais c'est un autre problème.)

en général, je le considère comme une odeur de code.

si votre classe est si compliquée, alors elle peut probablement être décomposée en de plus petits composants réutilisables.

ou cela signifie qu'il n'y a pas de hiérarchie de l'héritage là où il devrait y en avoir une.

pour les scénarios de génération de code c'est bien mais je pense que la génération de code est une autre odeur de code.

je suis en retard dans le jeu... mais juste mes 2 cents...

l'un des usages pourrait être de reformuler une classe god existante dans une base de code existante en classes partielles multiples. Cela pourrait améliorer la possibilité de découvrir du code - si la convention de nommage appropriée est suivie pour les noms de fichiers contenant les classes partielles. Cela pourrait également réduire le dépôt de code source - résoudre et fusionner dans une certaine mesure.

idéalement, une classe de Dieu devrait être ventilée dans plusieurs petites classes - chacun ayant une responsabilité unique. Parfois, il est perturbateur d'effectuer des remaniements de moyenne à grande envergure. Dans de tels cas, des classes partielles pourraient constituer un allégement temporaire.

Correction, comme Matt l'a souligné, les deux côtés de la partielle doivent être dans la même assemblée. mon mauvais.

Je l'utilise dans une couche d'accès aux données. Les classes générées comme le mapper et requêtes partielles. Si je dois ajouter une méthode mapper par exemple pour faire une charge fantaisiste qui n'est pas générée, je l'ajoute à la classe custom.

à la fin, le programmeur qui utilise la couche data dans la couche business ne voit qu'une classe avec toutes les fonctionnalités dont il a besoin. Et si la source de données change, les parties génériques peuvent facilement être générées sans écraser des trucs personnalisés.

je viens de trouver une utilisation pour les classes partielles. J'ai une classe [DataContract] que j'utilise pour transmettre des données au client. Je voulais que le client soit capable d'afficher la classe d'une manière spécifique (sortie texte). donc j'ai créé une classe partielle et j'ai dépassé la méthode de ToString.

parfois, vous pourriez trouver terriblement Vieux code au travail qui peut le rendre proche de l'impossible de refactor out en éléments distincts sans briser code existant.

quand on ne vous donne pas l'option ou le temps de créer une architecture plus authentique, les classes partielles rendent incroyablement facile de séparer la logique là où elle est nécessaire. Cela permet au code existant de continuer à utiliser la même architecture tout en se rapprochant d'une architecture plus concrète.

où que vous ayez utilisé les sections #region avant est probablement plus logique que des fichiers séparés dans les classes partielles.

j'utilise personnellement des classes partielles pour les grandes classes où les membres statiques vont dans un fichier et les membres d'instance dans l'autre.

EDIT: DSL Tools for Visual Studio utilise des classes partielles.

ainsi, c'est une caractéristique que beaucoup de code généré automatiquement utilise. Au lieu d'utiliser #region le code généré automatiquement va à un fichier et le code utilisateur (aussi appelé code personnalisé) va à un autre et même dans différents répertoires de sorte que le développeur ne se confond pas avec tant de fichiers sans signification.

il est bon d'avoir ce choix que vous pouvez combiner - mais pas forcé use-avec héritage

aussi, il peut être pratique de séparer la logique de certaines classes parmi plusieurs répertoires. Bien sûr, pour les machines, c'est la même chose, mais cela améliore l'expérience de lisibilité de l'utilisateur.