Dev Faq
0
votes

C # Y a-t-il un meilleur moyen d'utiliser le cas d'interrupteur / si-d'autre sur des types génériques

J'essaie actuellement de faire ressortir des types génériques. Donc, l'idée de base est d'avoir une méthode qui accepte un type générique et que des trucs différents en fonction duquel le type est passé.

Pour des raisons de simplicité, je voudrais simplement mettre en valeur l'utilisation de float , BOOL et défaut

La configuration ressemble à ceci (où t est un type générique défini par la classe elle-même): < / p> xxx

où dofloatstuff et doboolstuff ne sont que des méthodes qui ont 1 paramètre et un type de retour de leurs types respectivement.

Si je ne le fais pas comme ça (j'ai essayé certains typeof () Casting avant), le compilateur se plaint toujours qu'il ne peut pas lancer de t à float et vice versa, même que je suis assuré que ce serait le cas avec quelques déclarations de cas-Switch / if-else.

Quelqu'un peut-il savoir une meilleure façon de le faire?

Merci d'avance, Bothline

Edit: Étant donné que beaucoup de gens ont dit une sorte de la même chose, que je ne devrais pas utiliser des génériques du tout dans un cas comme ça ou que mes méthodes devraient être plus génériques elles-mêmes .. Mon problème ici est que j'ai besoin d'utiliser des méthodes tierces pour gérer les cas spéciaux que je vérifie (dans ce cas le float et BOOL types). Pour le cas par défaut, j'ai déjà tout manipulé de manière générique. Mais pour certains types définis, je ne peux tout simplement pas faire ça.

Pour aller un peu plus en détail pourquoi c'est le cas: Je travaille actuellement sur un plugin pour le "moteur unity". L'unité a intégré des méthodes pour afficher des types (type de tous types primitifs et certains types spécifiques à unité). J'ai une classe d'emballage générique qui devrait pouvoir contenir des types. Mais lorsque je veux afficher le contenu de cet emballage dans l'interface graphique que l'éditeur Unity propose, je dois utiliser les méthodes intégrées pour afficher les primitives (quelque chose comme Unityeditor.etitritrui.floatfield () ). Sans ces méthodes, je ne suis jamais capable d'afficher quoi que ce soit. Quelque chose d'autre qui peut être divisé en ces types peut alors être affiché de manière plus générique.

2 commentaires

Si dofloatstuff et Doboolstuff sont si différents qu'ils ne peuvent pas être "généralisés" alors vous n'avez aucune utilisation de génériques. Il suffit d'abandonner et d'avoir objet dostuff (valeur d'objet) .

@Dialecticus qui devrait être la seule option si vous ne connaissez pas le type de l'objet. Si le compilateur peut comprendre le type au moment de la compilation, il devrait utiliser la surcharge de la méthode, pas les génériques et le plus certainement pas objet .

3 Réponses :

7
votes

Ainsi, l'idée de base est d'avoir une méthode qui accepte un type générique et que des trucs différents selon lesquels sont transmis.

C'est la mauvaise idée. Ce n'est pas la façon dont les génériques devraient être utilisés. Dans un tel cas, vous devez utiliser la surcharge de la méthode pour créer le dostuff pour chaque type individuellement: xxx

Le point de générique consiste à vous permettre de vous permettre de Écrivez un code qui fonctionnera de la même manière sur différents types - il devrait donc être utilisé sur l'endroit où le type lui-même n'est pas pertinent pour le code (comme dans une collection générique) ou peut être exécuté avec une interface ou une classe de base tous les types acceptables. (ou hérite). À ce stade, les génériques ne sont généralement nécessaires que lorsque vous souhaitez qu'une méthode renvoie une implémentation spécifique d'une interface (ou de classe de base).

2 commentaires

Hey, merci beaucoup pour votre commentaire. Je suis d'abord édité mon poste initial pour me faire un peu plus clair, car je n'ai pas tout expliqué très bien. En raison, je voulais bien sûr gérer la plupart des cas de manière générique, il n'y avait que quelques cas particuliers que je dois régler. Mais bien oui, votre "ce n'est pas l'idée des génériques" m'a vraiment fait penser. Et je devrais pouvoir simplement utiliser la méthode dostuff de manière générique, puis hériter avec mes cas spéciaux et remplacer cette méthode de la bonne manière, car je n'aurai aucune vérification de type. plus. Merci beaucoup! :)

Heureux de vous aider :-)

1
votes

Laissez le compilateur le trier pour vous: 

protected void DoStuff(float v){}
protected void DoStuff(int v){}
// and so on
//and finally the default:
protected void DoStuff(object v){}

public void Work(T value)
{
    DoStuff(value)
}

0 commentaires
1
votes

Ce n'est pas la réponse courte, mais c'est la bonne façon (par de nombreuses normes). Il pourrait y avoir une réponse courte, mais si j'étais vous, je ne me dérangerais pas.

C'est l'odeur d'un motif d'usine. Un générique devrait être, comme le nom le suggère, générique et indifférent aux types si vous pouvez faire quelque chose comme ça. xxx

alors vous pouvez avoir une usine vous donner une usine Mise en œuvre correcte xxx

0 commentaires

Articles qui pourrait vous intéresser :

Calculer la différence dans l'échelle d'évaluation alphabétique
Ignorer la propriété de l'interface utilisateur Swagger
Comment détruire les éléments dynamiques du panneau dans le script Unity C #
Entity Framework Core 3.1 avec NetTopologySuite.Geometries.Point: SqlException: la valeur fournie n'est pas une instance valide de la géographie du type de données