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

J'utilise rarement #region car ils n'améliorent pas votre code. Il existe de nombreux moyens simples de naviguer dans votre code, même sans ajouts supplémentaires de Visual Studio. Si vous avez vraiment besoin de cacher une partie de votre code, vous devriez peut-être le réécrire ?

Answer 2

Je peux comprendre que vous vouliez "trier" votre code. D'abord les consts, ensuite les readonly static fields, les non-readonly static fields, les readonly instance fields, les non-readonly instance fields, les props, les constructors, les destructors, les méthodes publiques, les méthodes privées, les event handlers.

Mais pourquoi ajouter des régions alors que vous avez déjà trié votre code ? Concentrez-vous sur le fait de garder vos classes petites.

Answer 3

Je suggère l'approche suivante :

1. Divisez la classe en deux parties principales régions, Membres publics y Privé membres .

2. Dans chaque région principale, créez sous-régions par fonctionnalité logique. Par exemple, Initialisation , Facture gestion , Gestion des clients (ou tout autre type de services spécifiques au domaine offerts par votre classe).

Answer 4

J'étais autrefois comme vous ; je voulais tout organiser en régions spécifiques. J'ai essayé pendant un certain temps, mais je me suis ennuyé.

Il vaut mieux se contenter d'écrire les choses dans un ordre commun ; et, comme tout le monde l'a dit, ne pas avoir des classes si grandes qu'un tel schéma soit légitimement nécessaire.

La cohérence est le meilleur gage de lisibilité ; si vous présentez vos classes de la même manière, dans le même projet, et que vous les gardez concises, c'est à peu près tout ce que vous devez faire.

Il est maintenant très rare que j'utilise des régions, et je l'ai fait une ou deux fois (je pense), mais je ne pense certainement pas qu'une classe régulière devrait avoir un ensemble standardisé de régions. Notez que c'est juste que je n'y "crois" pas ; si cela fait flotter votre bateau, faites un essai, et restez cohérent, et la vie devrait être bonne.

Answer 5

Comme la plupart des posters, je penche pour l'évitement des régions.

Cependant, j'aime parfois replier les parties publiques/privées/protégées/internes. À cet égard, il est dommage que nous nous soyons écartés de la manière dont le C++ définit ces modificateurs d'accessibilité.

Réfléchissez à la manière dont vous voulez lire le code. Soit vous regardez l'interface publique, auquel cas la région publique (et probablement juste les signatures), soit vous implémentez (ou regardez autrement l'implémentation), auquel cas vous voulez probablement voir l'ensemble. Vous pouvez également implémenter une classe dérivée, auquel cas vous voulez voir les parties publiques et protégées. Vous pouvez aussi vouloir ajouter internal.

Puisque, dans tous les cas, vous voulez voir la section publique, je ne la place pas du tout dans une région.

En dehors de ces points de vue, je n'y vois guère d'avantages.