Existe-t-il un moyen standard de diviser une classe en régions ?

Question

Je me demandais s'il existe un moyen standard de diviser une classe en régions. Presque chaque projet utilise une "approche par région" différente (même les classes d'un même projet).

Nous accordons tellement d'attention aux conventions de dénomination et si peu à la structure de la classe. Je pense que l'introduction d'une certaine norme nous permettra de nous lancer beaucoup plus facilement dans un nouveau code.

J'utilise par exemple la méthode suivante :

public class SomeClass
{
     #region Consts
     #endregion

     #region Fields
     #endregion

     #region Properties
     #endregion

     #region Construction
     #endregion

     #region Public Methods
     // Class's API
     #endregion

     #region Overrides
     // Different region for each class override
     #endregion

     #region Private Helpers
     // private methods used only to support external API Methods
     #endregion
}

Ceci est pour une classe de base bien sûr. Quand la classe est plus compliquée, plus de régions sont introduites (Destruction, Méthodes Abstraites et ainsi de suite).

Qu'en pensez-vous ? Quelles régions utilisez-vous dans vos cours ?

EDIT

Après avoir lu certaines des réponses, j'ai l'impression que je dois affiner la question (Alt + Enter si vous voyez ce que je veux dire :)) :

Pensez-vous que l'utilisation de régions peut améliorer la lisibilité de votre code ? Si oui, pensez-vous que l'introduction d'une manière standard de le faire simplifiera la façon dont nous lisons le code des autres ?

Une autre édition

A propos de la question de la responsabilité unique - je n'ai pas introduit de régions comme "traitement des fichiers" ou "traitement des entrées". Les régions que j'ai utilisées sont celles qui seront probablement présentes dans n'importe quelle classe que vous écrirez. Parfois, je voudrai voir seulement l'API que cette classe expose et d'autres fois, je voudrai voir seulement les méthodes privées ou les surcharges. encore une fois, dans ce cas, je ne vois pas de mal à cacher un peu de code.

Answer 1

Utilisation de régions pour séparer les parties logiques ou syntaxiques d'une classe
Je n'utilise plus du tout les régions. J'avais l'habitude de les utiliser parce que mes classes étaient mal conçues et que l'ajout de régions semblait un moyen pratique de garder les parties logiques de ma classe distinctes. Maintenant je sais mieux.

D'un autre côté, l'utilisation de régions pour séparer les méthodes publiques des méthodes privées, les champs des propriétés, ou d'autres choses similaires, me convient. J'aime être capable de distinguer ces parties d'une classe en un coup d'œil. Mais au lieu de régions, je préfère simplement utiliser une ou deux lignes vierges supplémentaires entre ces zones. C'est suffisant pour les distinguer visuellement, sans ajouter d'encombrement.

Utilisation des régions pour cacher les détails explicites non pertinents de la mise en œuvre de l'interface
La seule chose que j'utilise actuellement pour les régions est pour explicite les implémentations de l'interface. Par exemple, la mise en œuvre de IEnumerable<T> nécessite la mise en œuvre d'un système non générique IEnumerable explicitement. Comme le code d'implémentation n'existe qu'à cause d'un artefact du framework et non parce que je veux qu'il soit là, et comme l'implémentation explicite ne fait que des appels triviaux à l'implémentation normale de toute façon, je me sens bien de le cacher dans une région.

Answer 2

Le seul endroit où j'ai utilisé des régions sans le regretter est dans une classe que j'ai construite qui enveloppe une énorme structure de données COBOL. Elle contient une classe privée avec un milliard de petits fichiers de longueur fixe. byte[] et les accesseurs qui utilisent l'option AsciiEncoding pour les manipuler. Une fois que j'ai fait fonctionner cette classe privée, il y a sept ans, je n'ai jamais eu à la regarder une seule fois. Donc c'est dans une région.

Mon sentiment général est qu'une fois qu'une classe atteint une certaine taille et complexité, s'il n'est pas possible de la refactorer pour la simplifier, il faut utiliser l'automatisation pour organiser ses membres. L'automatisation n'oublie jamais de placer un membre au bon endroit, pas plus qu'elle n'oublie de déplacer un membre si vous changez son nom ou son accès.

Je trouve également qu'une fois que vous avez de bonnes fonctions de navigation dans le code intégrées à votre IDE, il n'est pas nécessaire d'utiliser des outils de navigation. matière comment les membres d'une classe sont organisés. Une méthode n'est vraiment pertinente que dans le contexte des méthodes qui l'appellent, et une propriété n'est pertinente que dans le contexte des méthodes qui l'utilisent. Il y a parfois des exceptions (par exemple, si vous sous-classez la classe TextWriter il est quelque peu utile de pouvoir constater que l'option Write fonctionnent toutes de la même manière, même si elles ne s'appellent pas les unes les autres), mais la plupart du temps, je me contente de trier les membres d'une classe par leur nom. Cela m'évite d'avoir à décider "où vais-je mettre ce membre ?", ce qui, contrairement à beaucoup de décisions de style de codage à la volée, ne semble pas me permettre d'écrire un meilleur code.

Answer 3

J'utilise #regions pour rassembler les membres en groupes :
- constants
- méthodes statiques
- variables
- les méthodes

En dehors de cela, il m'arrive de classer les méthodes en plusieurs groupes en fonction de leur fonctionnalité. Mais cela n'est généralement nécessaire que pour les grandes classes de bibliothèque polyvalentes comportant de nombreuses méthodes.

Answer 4

Oui, j'ai pensé à ça aussi. J'ai créé ma propre convention il y a quelques temps, c'est à peu près comme la tienne, mais avec une division Root supplémentaire pour les statiques et les instances Je veux dire qu'il y a deux régions principales, une pour static et une pour instance, les deux incluent tout ce que tu as mentionné (sauf const qui est une région séparéeXD)

Answer 5

J'admets être quelqu'un qui utilise beaucoup les régions. J'enveloppe toutes mes méthodes dans leur propre région mais exclut les paramètres. (par exemple, #region GetStuff par opposition à GetStuff(arg1, arg2...). Mes raisons sont :

1. Lorsque je réduis une propriété qui possède son propre champ privé, je veux que le champ soit réduit avec la propriété. Je veux voir une ligne pour le nom de la propriété et non pas potentiellement trois lignes pour la propriété, son champ privé et ses commentaires effondrés. Avec .NET 3.5 et les propriétés automatiques, je ne les entoure pas d'une région car elles font déjà une ligne et je peux tolérer la ligne supplémentaire de réduction avec les commentaires. Je trouve qu'il est plus difficile de lire et d'organiser les variables privées qui n'existent que grâce à une méthode de propriété.

2. Je veux que les commentaires sur la propriété ou la méthode s'effondrent avec la méthode. À l'époque, j'avais l'habitude de toujours placer mes commentaires à l'intérieur de la méthode, spécifiquement pour cette raison et pour que si je copie la routine ailleurs, les commentaires l'accompagnent. MS a décidé que les commentaires devaient se trouver à l'extérieur de la méthode, ce qui signifie que lorsque je réduis la méthode, je dois réduire séparément ses commentaires.

3. Mes classes ne comportent généralement pas plus d'une douzaine de méthodes. Lorsque je réduis toutes les méthodes de la classe, je peux voir l'ensemble de la classe et trouver rapidement ce que je veux. Je trouve cela beaucoup plus rapide que de naviguer dans la liste déroulante ou d'essayer d'utiliser les commandes du clavier pour parcourir ou trouver la méthode que je veux.

4. Lorsque j'ai une méthode avec une ou plusieurs surcharges, je les mets dans la même région. Cela rend les choses vraiment agréables lorsqu'elles sont réduites, car il y a moins de lignes mais elles sont regroupées logiquement.

5. Enfin, le fait de réduire les régions permet de filtrer plus facilement le flot d'autres méthodes, propriétés et commentaires qui ne me concernent pas actuellement. Quand vous avez une classe avec disons une douzaine de méthodes qui sont chacune disons une douzaine ou deux lignes, réduites, il y a pas mal de bruit avec les différentes couleurs, les commentaires réduits séparément, les variables membres privées etc . Comme les régions sont grises par défaut, les réduire revient à les mettre en arrière-plan, alors que le code dont je me soucie, qui est développé, est bien visible.

J'évite les régions qui ne sont pas destinées à cet usage.