J'ai un code très similaire à cet exemple trois fois dans un code derrière. Chaque fois que le commutateur bascule d'une option qui lui est envoyée. Chaque temps le code à l'intérieur du boîtier est exactement le même sauf pour un paramètre basé sur le cas. Utilise un commutateur / un cas et des méthodes le meilleur moyen pour faire ça? Devrais-je penser à utiliser certains types de motifs de conception afin d'éviter la structure de commutation / case répétée?
string option = dropDownList.SelectedValue.ToString();
switch (option.ToUpper())
{
case "ALPHA":
// do repeative code method here; only change is a parameter
break;
case "BRAVO":
// do repeative code method here; only change is a parameter
break;
case "CHARLIE":
// do repeative code method here; only change is a parameter
break;
case "DELTA":
// do repeative code method here; only change is a parameter
break;
default:
break;
}
7 Réponses :
peut-être une transformation de Cela vous permettrait de déposer l'instruction de commutation et de simplement alimenter la méthode du paramètre transformé. P>
Vous pouvez construire une table pour convertir chaîne code> vers valeur de paramètre code>.
En fait, si vous avez plus de 6 chaînes dans votre commutateur, la solution de recherche sera ce que l'IL fera autrefois compilé (c'est un trygetvalue en fait, mais l'idée est la même)
+1, mais avec if (lookeup.ecteurvalue (option, valeur de sortie)) {...}
+1 Option 1. Neuste, Concise, Facile à lire, évite l'obscosité inutile d'oop
+1 Aussi pour option 1. Ne répétez pas le code si vous n'êtes pas obligé.
Alors que celui-ci est jolie, je pense que ce que j'essaie de faire est de faire quelque chose d'usine créé. Merci pour les exemples!
La clé de ce problème consiste à rendre les objets stockés dans la liste déroulante fournissent le paramètre (directement ou en indexation dans un tableau). Ensuite, l'instruction de commutation peut être supprimée complètement. P>
Si le paramètre est une propriété de l'objet qui apparaît dans la liste déroulante, cela fournira la valeur très efficacement. P>
Si les valeurs de la liste déroulante peuvent fournir un index numérique dans une matrice de valeurs de paramètre, cela battra une série de comparaisons de chaîne en termes d'efficacité d'exécution. P>
L'une de ces options est plus propre, plus courte et plus facile à entretenir que d'allumer une chaîne. P>
Ceci est probablement surchargé pour ce que vous faites, mais le code pourrait em> finir le nettoyant. string option = dropDownList.SelectedValue.ToString();
AlphabetChar alphabetChar = AlphabetCharFactory.GetByName(option);
alphabetChar.DoSomething();
Tout ce que vous avez fait, il y a ajouté une bande de bruit de oop - de quelle manière cela résoudra-t-il le problème, à l'exception de l'obscurcissement et de le rendre plus difficile à lire?
Comme je l'ai dit deux fois i>, il est probablement trop excité; Mais c'est aussi une solution viable (nous déclarons souvent que c'est simple quand il n'est vraiment pas) bien que le porno OOP pour le cas simple. Si @chris remarque plus tard que l'un des cas est différent, cette approche sera plus propre que d'avoir si (option == "alpha") {...} else {...} code> jonchée le code.
Je pense que je déplacerais l'instruction de commutation dans une fonction distincte et que je renvoie la valeur de paramètre pour chaque cas: alors vous pouvez simplement appeler votre méthode de travail une fois: p > Si vous ne souhaitez pas exécuter votre méthode de travail pour la cause par défaut ou si vous avez plus d'une valeur de paramètre, vous pouvez modifier la méthode GetParameter pour utiliser Paramètres de sortie: p> et appelez-le comme ceci: p>
Les compilateurs sont très bons pour optimiser les constructions de commutation / cas; Le CLR la transformera probablement dans une table de recherche ou quelque chose de même rapide, alors roulant de la main de votre propre version telle que Henk Holterman suggère n'est pas ce que je recommanderais. Le CLR peut faire un meilleur travail que vous ne pouvez en choisir le meilleur algorithme.
Si c'est une question d'élégance ou de maintenabilité, plusieurs commutateurs / cas épargnent de la même classe effectuant des fonctions similaires, puis d'une façon de l'améliorer est d'encapsuler toutes les fonctionnalités liées à un seul "cas" dans sa propre instance de classe, comme: P> puis dans votre classe / contrôle / page: p > private void control1_SomeEvent(object sender, EventArgs e)
{
MyOption option = GetOptionFromDropDown();
DoSomething(option.ID);
}
private void control2_SomeEvent(object sender, EventArgs e)
{
MyOption option = GetOptionFromDropDown();
DoSomethingElse(option.Value);
}
C'est en fait ce que j'ai envisagé d'essayer de mettre en œuvre. J'ai la nécessité de créer un tas d'événements et / ou de méthodes différents basés sur le paramètre Options Créé. Ainsi, alors que les autres sont fantaisistes, celui-ci travaille pour le problème que je regarde. Merci.
hm, je pense que la solution très rapide utilise le dictionnaire. Le dictionnaire est une structure très rapide lorsque vous utilisez une clé -> la logique de valeur. Donc, dans votre cas, vous pouvez utiliser ceci:
public string SomethingToReturn(string key, string value)
{
if (proccessValues.ContainsKey(name))
{
return proccessValues[name].Invoke(value);
}
return string.Empty;
}
Quels types de choses sont stockées dans la liste déroulante? Pourriez-vous faire les options de la liste une énumération? Quel type est le paramètre?
Les choses stockées sont-elles stockées dans la liste déroulante générée par l'utilisateur? J'aimerais pouvoir voir plus de votre code! Il peut y avoir d'autres possibilités d'amélioration ici. Le Toupper () indique des drapeaux rouges.