Utiliseriez-vous des régions dans les déclarations de commutateur / énumération longues?

Question

Je me suis récemment rendu compte qu'il était nécessaire (oui, nécessaire) de définir des déclarations switch absurdement longues et des déclarations enum en code C #, mais je me demande quel est le meilleur moyen de les scinder en sous-sections logiques. . Dans ma situation, les valeurs enum et les cas (basés sur les valeurs enum) ont des regroupements assez clairs, mais je ne suis pas sûr de savoir comment refléter cela dans le code.

Notez que dans mon code, j'ai environ 5 groupes contenant chacun entre 10 et 30 valeurs enum / cas.

Les trois options vaguement raisonnables que je peux envisager sont les suivantes:

1. Définissez #region des blocs autour de tous les groupes logiques de valeurs d'observations / enumères de la déclaration (éventuellement séparés par des lignes vides).
2. Commentez chaque groupe avec son nom, avec une ligne vide avant chaque commentaire de nom de groupe.
3. Ne faites rien du tout - laissez simplement le commutateur / enum sous la forme d'une liste énorme de cas / valeurs.

Lequel préférez-vous? Souhaitez-vous traiter les enums et les commutateurs séparément? (Cela me semblerait un peu étrange.) À présent, je ne dirais pas qu'il existe une réponse bonne / mauvaise à cette question, même si je serais néanmoins très intéressé d'entendre Qu'est-ce que le consensus général des points de vue?

Remarque 1: Cette situation où je pourrais potentiellement avoir une déclaration d'enum extrêmement longue de 50/100 + valeurs est malheureusement inévitable (et de même avec le commutateur), car je tente d'écrire un lexer (tokeniser), et cela semblerait donc l'approche la plus raisonnable pour plusieurs raisons.

Note 2: Je suis pleinement conscient du fait qu'il existe déjà plusieurs questions en double sur la question de savoir s'il faut utiliser des régions dans le code général (pour la structuration des classes principalement), mais je pense que ma question est beaucoup plus spécifique et n'a pas encore été abordée.

Answer 1

Bien sûr, région de ces choses. Ils ne changent probablement pas beaucoup et, lorsqu'ils le font, vous pouvez développer la région, y apporter vos modifications, la réduire et passer au reste du fichier.

Ils sont là pour une raison, utilisez-les à votre avantage.

Answer 2

Vous pourriez aussi avoir un Dictionnaire < [votre_num_enum], Action > (ou Func au lieu de Action) ou quelque chose comme ça (vu que vos fonctions ont une signature similaire). Ensuite, vous pouvez utiliser un commutateur au lieu de:

        switch (item)
        {
            case Enum1: func1(par1, par2)
                break;
            case Enum2: func2(par1, par2)
                break;
        }

vous pourriez avoir quelque chose comme:

public class MyClass
{
    Dictionary<int, Action<int, int>> myDictionary;
    //These could have only static methods also
    Group1Object myObject1;
    Group2Object myObject2;

    public MyClass()
    {
        //Again, you wouldn't have to initialize if the functions in them were static
        myObject1 = new Group1Object();
        myObject2 = new Group2Object();
        BuildMyDictionary();
    }

    private Dictionary<int, Action<int, int>> BuildMyDictionary()
    {
        InsertGroup1Functions();
        InsertGroup2Functions();
        //...
    }

    private void InsertGroup2Functions()
    {
        myDictionary.Add(1, group2.AnAction2);
        myDictionary.Add(2, group2.AnotherAction2);
    }

    private void InsertGroup1Functions()
    {
        myDictionary.Add(3, group1.AnAction1);
        myDictionary.Add(4, group1.AnotherAction1);
    }


    public void DoStuff()
    {
        int t = 3; //Get it from wherever
        //instead of switch
        myDictionary[t](arg1, arg2);
    }
}

Answer 3

Je le laisserais comme une énorme liste de cas / valeurs.

Answer 4

Si certains cas ont le même bloc de code, l'utilisation du modèle de conception Stratégie peut supprimer le bloc de commutateur. Cela peut créer beaucoup de classes pour vous, mais montrera à quel point c'est complexe et divisera la logique en petites classes.

Answer 5

Débarrassez-vous des énumérations et faites-en des objets. Vous pouvez ensuite appeler des méthodes sur vos objets et conserver le code séparé, maintenable et non un cauchemar.

Il existe très peu de cas dans lesquels vous auriez réellement besoin d'utiliser une énumération au lieu d'un objet et où personne n'aime les longues instructions switch.

Answer 6

Voici un bon raccourci pour les utilisateurs des régions.

Je basculais entre Eclipse et Visual Studio lorsque j'ai essayé de passer en mode plein écran dans VS en appuyant sur

Ctrl-M-M

et voilà, la région est fermée et étendue!