È una best practice con Enum in C #

La risposta più basilare alla tua domanda è questa: la maggior parte degli IDE C # che conosco hanno un'opzione di Refactoring che ti permette facilmente di rinominare variabili e riferimenti, come i tipi di enumerazione. Se evidenzi TeamLead, ovunque venga utilizzato, fai clic con il pulsante destro del mouse e cerca l'opzione Rinomina, dovresti essere in grado di modificare i riferimenti in tutti i file di codice del tuo progetto. Se fai riferimento ad esso come una stringa, potrebbe essere utile eseguire una ricerca di testo completo e gestire singoli casi.

Tuttavia, la mia risposta completa, che posso solo sperare che ti interessi, è che questo è il modo sbagliato di fare le cose in un linguaggio orientato agli oggetti. Dovresti soprattutto prendere nota delle volte in cui stai separando grandi blocchi di logica da un if / else / switch, e anche usando parte di un blocco in un altro, come un tempo in cui la progettazione orientata agli oggetti ti può aiutare. Ecco come lo farei, in pseudo-codice incompleto:

abstract class ProjectMember {
    public abstract void reassignTask(Task t);
}

class Manager : ProjectMember {
    public void reassignTask(Task t) {
        // TODO: manager case
    }
}

class TeamLead : ProjectMember {
    public void reassignTask(Task t) {
        // TODO: TeamLead case
    }
}

class Associate : ProjectMember {
    public void reassignTask(Task t) {
        // TODO: associate case
    }
}


// this is the function where you'd be getting rid of a switch statement, by way of the above code.
void reassignMemberTask(ProjectMember mem, Task t) {
    mem.reassignTask(t);
}

Rinominare un elemento di una enumerazione non è un problema: Visual Studio lo fa per te, assicurandoti che ogni riferimento ad esso venga rinominato.

D'altra parte, possono sorgere altri problemi quando "riusare" gli elementi in questo modo:

1. Comportamento aziendale

   Immagina che TeamLead sia un lead della squadra, mentre Lead è uno sviluppatore principale in una squadra. Immagina il seguente pezzo di codice:

   if (role != Designation.TeamLead)
   {
       // The user cannot fire a member of a team: only a team lead can do it.
       this.DenyFiringTeamMember();
   }
   

   Se si rinomina il ruolo, mancheranno le regole aziendali, ovvero il fatto che solo un responsabile della squadra può licenziare un membro del team. Ora, lo sviluppatore principale può licenziare altri sviluppatori, mentre ci si aspetta che solo il team leader sia in grado di farlo.

2. Dipendenze

   A meno che tu non sia Google , potresti avere dipendenze da progetti esterni. Visual Studio non sarà in grado di trovarli, quindi il problema si presenterà la prossima volta che apri una soluzione che fa riferimento al vecchio TeamLead .

3. ToString

   A volte, e questa è una pratica estremamente negativa, l'elemento dall'enumerazione viene convertito in stringa e quindi utilizzato in un confronto o memorizzato nel database, ecc. Esempio:

   if (role.ToString() == "TeamLead")
   {
       // I never understood how to compare variables, and I don't care.
   }
   

   Rinominare l'elemento spezzerà quei pezzi di codice. Forse è meglio: sarai in grado di trovarli e riscriverli correttamente.

Utilizza solo uno strumento di refactoring. Non puoi eludere il fatto che se rinomini qualcosa devi rinominarlo ovunque, ma uno strumento di refactoring lo renderà semplice.

La maggior parte degli strumenti di refactoring può facilmente aiutare con questo. Permette la ridenominazione di massa basata sulla semantica del linguaggio, non solo la sostituzione del testo.

Ma se utilizzi enumerazioni complesse per la logica aziendale, inizierei a pensare se non dovresti utilizzare OOP appropriato.

Risponderò, non perché penso che le altre risposte siano cattive, ma perché penso che ci sia un'altra cosa da dire in questo caso.

Abbiamo due domande in una:

1. Informazioni sulle migliori pratiche per te Enum
2. Informazioni sul refactoring di un Enum

1)Is this a Best Practice with Enum in C#?

Bene, nel tuo caso, dal momento che Enum sembra essere un po 'gerarchico, li definirei come flag e ne traggo vantaggio quando utilizzo e confronti i valori.

[Flags]
enum Designation
{
    None = 0x0,
    TeamLead = 0x1,
    Manager = 0x2,
    Associate = 0x4
}

Quindi potresti usare un codice come questo:

    string CheckAboveManager(Designation designation)
    {
        if (designation >= Designation.Manager)
            return "It's a manager or higher";
        return "Is lower than manager";
    }

L'altra opzione di usare una struttura orientata agli oggetti funzionerà solo se c'è un comportamento o una struttura specifici con cui vuoi separare le preoccupazioni. Se si tratta solo di definire una proprietà (che è il motivo per cui esistono enumerazioni!), Non vedo la necessità di creare ereditarietà, ma se è il caso, utilizzare risposta accettata .

2) Now if we decide to change the enum element from "TeamLead" to "Lead" then we have to modify the above line of code as well i.e. designation == Designation.TeamLead to designation == Designation.Lead

Bene, è già stato ben spiegato che il refactoring non è un problema se stai usando VS IDE, puoi anche usare altri strumenti come DevExpress CodeRush! o ReSharper a ottenere un risultato ancora migliore (e molto sicuro) dal refactoring.

Se si rinomina il membro enum in una DLL, il codice del chiamante deve essere modificato e ricompilato.

Questo potrebbe rompere la compatibilità binaria. È necessario assicurarsi che il codice del chiamante sia modificabile.