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.