de MSDN : P>
En éliminant les fonts inutiles, les conversions implicites peuvent améliorer la lisibilité du code source. Cependant, étant donné que des conversions implicites peuvent se produire sans les spécifier du programmeur, il faut prendre soin de prévenir des surprises désagréables. En général, les opérateurs de conversion implicites ne doivent jamais lancer d'exceptions et ne jamais perdre d'informations afin de pouvoir être utilisées en toute sécurité sans la conscience du programmeur. Si un opérateur de conversion ne peut pas répondre à ces critères, il devrait être marqué explicite. P> blockQuote>
Pendant que je ne suis pas en désaccord avec un point particulier, et je conviens que tout est très bon, y a-t-il déjà une raison suffisante pour justifier de casser la partie des conversions implicites qui ne lance pas d'exceptions? P>
Le cas particulier que j'ai devant moi est un où: p>
- J'ai une fonction, qui renvoie un objet de collecte personnalisé (nous l'appellerons
foocollection code>). Li>
- Cette fonction peut renvoyer des collections avec un seul élément et Il peut être déterminé à partir du code source si cela se produira ou non fort>. (Par ceci, je veux dire juste l'appel de la fonction, pas la fonction elle-même) li>
- Si cela se produit, il est probable que l'utilisateur souhaite ce seul élément, plutôt qu'une collection avec un seul élément. Li> ol>
Maintenant, je jette s'il faut inclure une conversion implicite de
foocollection code> =>
foo code> pour masquer ce petit détail de mise en œuvre, mais cette conversion ne fonctionnera que s'il ya est un seul élément de la collection. P>
est-il correct de lancer une exception
code> dans ce cas? Ou devrais-je utiliser une fonte explicite à la place? Toute autre idée sur la manière dont je pouvais traiter cela (non, en raison des détails de la mise en œuvre, je ne peux pas simplement utiliser deux fonctions)? P>
edit: strong> Je pense que cela mérite de noter que
foocollection code> ne met pas en œuvre aucune interface ou étendre réellement
collection code> comme nom de nom pourrait impliquer, D'où les réponses à base de Linq sont inutiles. De plus, alors que la collection met en œuvre un indice numérique, il n'est pas le moyen le plus intuitif de traiter la collection car elle s'appuie principalement sur l'indice nommé. P>
4 Réponses :
La distribution doit être explicite. Il sera très étrange de pouvoir attribuer un Cela étant dit, les lancers IMHO ne sont pas un bon moyen de le faire. Même si vous le disez non, je vais utiliser une fonction parce que même si vous n'avez pas de contrôle sur la mise en œuvre de ces classes, vous pouvez au moins ajouter des méthodes d'extension comme foocollection code> à un
FOO code> sans au moins une coulée. P>
FOO Tofoo (cette collection FOOCOLLECTION) CODE > Pour faire le travail. P>
Je suis sûr que 50% sûr que cela ne fonctionne pas non plus que cela se trouve dans le contexte des types C # 4.0 et dynamique
c'est à dire. Je ne sais pas si le routage dynamique prend en compte des méthodes d'extension ou non. Dang ça, maintenant j'ai autre chose que je veux essayer!
Je suis avec les lignes directrices: vous ne devriez jamais jeter d'une conversion implicite.
Je ne fournirais certainement pas une conversion implicite dans ce cas. Même l'idée d'une fonte explicite me sens tort: Pourquoi ne laissez-vous pas simplement le code appelant Vous inquiétez de la conversion de foo x = (foo) foocollection code> ne semble pas juste raison. P>
foocollection code> à
foo code>? Le code serait beaucoup plus intuitif pour tout le monde: p>
foo x = (foo) foocollection code> ne serait pas "juste" non plus (bien que cela soit compilé).
foo x = (foo) foocollection.x () code> serait la façon dont il serait utilisé.
x () étant une fonction qui renvoie un sous-ensemble de 1 article de Foocollection.
De toute façon, vous essayez toujours de jeter une certaine collection de foo code> à
foo code> lui-même, qui se sent bizarre pour moi. Pourquoi ne pas simplement laisser le code d'appel de
foo x = foocollection.x () [0] code> ou quelque chose de similaire?
Entre autres choses, il se sent désordonné. Mais jetant une exception d'une conversion implicite ne se sent pas non plus. Oh bien, je suppose que tellement a parlé de toute façon quand même :)
Je voudrais que le mot est légèrement différent: tout instance d'objet qui jette jamais lors de la conversion implicite doit être considéré comme cassé. Si par ex. Une instance d'objet non threadsafe devient corrompue à la suite d'actions simultanées par plusieurs threads, il peut être approprié pour cette instance de jeter une exception dans ce qui serait normalement un typast d'élargissement, mais seulement parce que l'instance est cassée I>.
Une copnversion implicite qui ne fonctionne que s'il n'y a que 1 article dans la collection? Donc, en fait, cela ne fonctionne pas la plupart du temps? P>
Je ne ferais jamais cette conversion implicite. Coller avec explicite. Si le programmeur utilisant votre fonction souhaite avoir le seul élément, il devrait simplement dire à votre classe. P>
Ce n'est clairement pas correct. jamais strong> Utilisez des exceptions pour mettre en œuvre la logique! p>
Vous pouvez utiliser le linq-instruction foocollection.firstordfault () code>, qui donnera null ou le premier élément. P>