J'ai deux méthodes qui sont des surcharges de l'autre dans mon exemple, la surcharge de getPrice (make, modèle, année) est peu coûteuse à exécuter, mais la méthode GetPrice (Vinnumber) est cher. Le problème est que la méthode coûteuse a le moins de paramètres et il apparaît d'abord dans le C # Intellisense. Les deux méthodes sont valides, mais je souhaite encourager les gens à appeler la méthode bon marché. Mais les gens ont tendance à ne pas regarder à travers toutes les surcharges d'IntelliSense avant de choisir une méthode à appeler, et le coûteux est appelé trop souvent dans la base de mon entreprise. est là un moyen de dire à Visual Studio de donner "priorité Intellisense" à une méthode particulière afin qu'il apparaisse d'abord?
4 Réponses :
Ne le pense pas.
Sauf si vous écrivez un plug-in IntelliSense (comme Restosens) et détournez l'intellientense par défaut et créez un programme pour les utilisateurs d'attribuer la priorité.
Eh bien, je suppose qu'il obtient quelque chose comme une [propriété] pour définir dans le fichier source pour "indiquer" Intellisense sur quelle surcharge prend la priorité.
Que se passe-t-il est:
Ce que vous pourriez envisager de faire est, au lieu de surcharges, nommer les membres les mêmes au début et différent à la fin ( Sinon, faites-leur de véritables surcharges mais utilisez la documentation XML pour mettre un avertissement clair sur le lent. getMake vs getmakeslow , mais évidemment quelque chose de mieux que cela) alors ils se présentent ensemble dans IntelliSense, mais il est communiqué que vous devriez utiliser.
C'est ce que je pensais que je me suis souvenu aussi, mais un test rapide montre moins de paramètres = d'abord.
Seulement une solution que je peux offrir est des commentaires, mais cela ne signifie pas que l'utilisateur va faire attention à eux:
Vous pouvez décorer la méthode avec la balise obsolète, qui générera également un avertissement ou une erreur en fonction des paramètres.
Le résumé apparaît dans IntelliSense, mais les remarques ne le font pas. (Les deux apparaîtront dans la documentation générée.) De plus, la chose #warning ne semble pas une bonne option, car elle apparaît comme un avertissement dans la méthode d'origine, pas à l'endroit où elle s'appelle.
Kyralessa, je pensais que l'étiquette de la remarque faisait partie de IntelliSense, mais juste testé et confirmé qu'ils ne le sont pas. Bon point sur l'avertissement, obsolète est la voie à suivre pour cet itinéraire. Merci pour l'entrée, j'ai édité ma réponse.
L'attribut [obsolète] avertit l'utilisateur, mais n'affecte pas l'ordre IntelliSense (au moins pas dans mon studio Visual 2012).
Je ne connais pas votre question générale, mais ce cas spécifique pourrait peut-être être résolu avec la nommée par ex. Geprice pour la version bon marché et la queryprice ou la prores de recherche pour la version coûteuse (pour indiquer qu'il va aller parler à une base de données). Juste une pensée.
Et si vous avez besoin de conserver la surcharge coûteuse pour la compatibilité, marquez-la avec l'attribut éditeur (éditeurballestate.Never) pour le cacher d'IntelliSense.
Je me demanderais de la sagesse d'avoir trois appels de base de données là-bas. Vous pouvez sûrement écrire une requête qui renvoie toutes les données dont vous avez besoin lors de la saisie de la base de données une seule fois.
@Itwllson: [l'attribut éditeur d'éditeur (éditorrowstable.Never)] fonctionne réellement pour vous?
Cory: J'ai eu lieu sur les limites de l'Assemblée. Il ne semble pas fonctionner dans un projet.
Supprimé mon commentaire précédent depuis que j'ai vu votre mise à jour sur ce ne sont qu'un exemple. Dans tous les cas, le thème de mon message est toujours valide, ce qui est peut-être en cache des informations de la méthode coûteuse pour que cela soit moins cher et que le problème initial disparaisse?