Je suis la programmation en C # et c'est plus une question de pratiques optimales.
Je voulais créer une méthode surchargée et effectué accidentellement deux méthodes avec les mêmes types de valeur que des arguments. Je voulais utiliser le même nom de méthode pour garder des choses simples lorsque l'écriture de code plus tard, j'ai ajouté un autre argument d'intensité en tant que surcharge à la surcharge juste pour la séparer de la première méthode. Cela ne semble pas être une bonne pratique de codage pour moi, mais cela a fonctionné. P>
Exemple ici: P>
public static void SetBalance(Customer cust, int index) { cust.Balance = balanceList[index]; } public static void SetBalance(Customer cust, int value, int notUsed) { cust.Balance += value; }
3 Réponses :
Lorsque vous surchargez un constructeur, vous ne devez pas disposer de deux constructeurs avec le même modèle d'argument que comme exemple, les deux constructeurs ont le même motif d'argument afin que vous fines avec une erreur lors de la compilation. Pour contourner cela, échangez simplement les arguments sur le deuxième constructeur comme P> Cela évitera des conflits. P> P>
IMO, l'échange de la commande rend difficile la lecture des surcharges d'IntelliSense que vous tapez (entre autres). Regardez le graphiques.Drawstring code> surcharge pour un exemple
Peut-être que vous devriez aussi faire la marque Microsoft. Parce que c'est où j'ai eu l'idée à l'origine!
Vous ferez mieux de nommer la première méthode quelque chose comme La deuxième méthode serait mieux nommée quelque chose comme Rafraîchissance code>, puisque la valeur résultante du solde du client n'est pas liée aux arguments présents dans la méthode. P>
régalance code> ou
incalbalance code> pour des raisons similaires. Deux méthodes avec des comportements clairement différents ne doivent pas avoir le même nom. P>
Le problème que je vois ici est la convention de dénomination. Ces deux méthodes effectuent différentes opérations, vous devez donc leur donner des noms propres à la configuration () et en complément () etc. p>
Pourquoi avez-vous besoin d'une méthode pour simplement définir une propriété?
Setbalance () Code> Ne fait rien de plus simple, plus court, plus propre ou plus clair pour tout acteur appelant
Setbalance code>.
Pourquoi une méthode qui incristent l'équilibre étant donné le nom Set B> Solde? En tout état de cause, cela est au mieux "ne fais pas cela", et à la pire une question principalement basée sur l'opinion. Je pense que vous constaterez que chaque fois que vous rencontrez dans ce type de situation, il y a de meilleurs noms que vous pouvez choisir pour la méthode. Alors, fais ça.