Est-il suffisant que les méthodes soient distinguées uniquement par le nom de l'argument (pas le type)?

Suffit-il que les méthodes se distinguent uniquement par le nom de l'argument (pas le type) ou vaut-il mieux le nommer plus explicitement?

Par exemple T Find<T>(int id)vs T FindById<T>(int id).

Y a-t-il une bonne raison de le nommer plus explicitement (c'est-à-dire d'ajouter ById) ou de ne garder que le nom de l'argument?

Une des raisons auxquelles je peux penser est lorsque les signatures des méthodes sont identiques mais que leur signification est différente.

FindByFirstName(string name) et FindByLastName(string name)

Bien sûr, il y a une bonne raison de le nommer plus explicitement.

Ce n'est pas principalement la définition de la méthode qui devrait s'expliquer d'elle-même, mais l' utilisation de la méthode . Et tandis findById(string id)que find(string id)les deux se passent d'explication, il y a une énorme différence entre findById("BOB")et find("BOB"). Dans le premier cas, vous savez que le littéral aléatoire est en fait un identifiant. Dans ce dernier cas, vous n'êtes pas sûr - cela pourrait en fait être un prénom ou autre chose.

Avantages de FindById () .

1. Avenir épreuvage : Si vous commencez avec Find(int), et ont plus tard d'ajouter d' autres méthodes ( FindByName(string), FindByLegacyId(int), FindByCustomerId(int), FindByOrderId(int), etc.), les gens comme moi ont tendance à passer des heures à la recherche pour FindById(int). Pas vraiment un problème si vous pouvez et va changer Find(int)pour FindById(int)une fois qu'il devient nécessaire - épreuvage avenir est au sujet de ces cas s.

2. Plus facile à lire . Findest parfaitement bien si l'appel ressemble à record = Find(customerId);Yet FindByIdest légèrement plus facile à lire si c'est le cas record = FindById(AFunction());.

3. La cohérence . Vous pouvez systématiquement appliquer le motif FindByX(int)/ FindByY(int)partout, mais Find(int X)/ Find(int Y)n'est pas possible car ils sont en conflit.

Avantages de la recherche ()

• BAISER. Findest simple et direct, et operator[]c’est l’un des 2 noms de fonction les plus attendus dans ce contexte. (Certaines alternatives populaires étant get, lookupou fetch, selon le contexte).
• En règle générale, si vous avez un nom de fonction qui est un seul mot bien connu qui décrit précisément ce que fait la fonction, utilisez-le. Même s'il existe un nom de plusieurs mots plus long, il est légèrement meilleur pour décrire le rôle de la fonction. Exemple: Length vs NumberOfElements . Il y a un compromis, et où tracer la ligne fait l'objet d'un débat en cours.
• Il est généralement bon d'éviter les redondances. Si nous regardons FindById(int id), nous pouvons facilement supprimer la redondance en la changeant en Find(int id), mais il y a un compromis - nous perdons un peu de clarté.

Sinon, vous pouvez obtenir les avantages des deux en utilisant des identifiants fortement typés:

CustomerRecord Find(Id<Customer> id) 
// Or, depending on local coding standards
CustomerRecord Find(CustomerId id) 

Implémentation de Id<>: Taper fortement les valeurs d'ID en C #

Les commentaires ici, ainsi que dans le lien ci-dessus, ont soulevé de nombreuses préoccupations à propos Id<Customer>desquelles j'aimerais aborder:

• Préoccupation n ° 1: c'est un abus de génériques. CustomerIdet OrderIDsont de types différents ( customerId1 = customerId2;=> bon,customerId1 = orderId1; => mauvais), mais leur implémentation est presque identique, nous pouvons donc les implémenter avec copier-coller ou avec métaprogrammation. Bien qu'il soit utile dans une discussion de révéler ou de cacher le générique, la métaprogrammation est ce à quoi servent les génériques.
• Problème 2: Cela n'arrête pas les erreurs simples. / C'est une solution à la recherche d'un problème Le problème principal qui est résolu par l'utilisation d'identifiants fortement typés est le mauvais ordre des arguments dans un appel à DoSomething(int customerId, int orderId, int productId). Les identifiants fortement typés préviennent également d’autres problèmes, y compris celui sur lequel l’OP a été interrogé.
• Problème 3: Il ne fait que masquer le code. Il est difficile de dire si un identifiant est retenu int aVariable. Il est facile de savoir qu'un identifiant est retenu Id<Customer> aVariableet nous pouvons même dire qu'il s'agit d'un identifiant client.
• Problème 4: ces identifiants ne sont pas des types forts, mais des wrappers. Stringest juste une enveloppe autour byte[]. L'emballage ou l'encapsulation n'est pas en conflit avec le typage fort.
• Préoccupation n ° 5: c'est trop technique. Voici la version minimale, bien que je recommande d’ajouter operator==et operator!=aussi, si vous ne voulez pas compter exclusivement sur Equals:

.

public struct Id<T>: {
    private readonly int _value ;
    public Id(int value) { _value = value; }
    public static explicit operator int(Id<T> id) { return id._value; }
}

Une autre façon de penser à cela consiste à utiliser le type safety de la langue.

Vous pouvez implémenter une méthode telle que:

Find(FirstName name);

Où FirstName est un objet simple qui enveloppe une chaîne qui contient le prénom et signifie qu'il ne peut y avoir aucune confusion quant à ce que fait la méthode, ni dans les arguments avec lesquels elle est appelée.

Je voterai pour une déclaration explicite comme FindByID .... Le logiciel devrait être construit pour le changement. Il devrait être ouvert et fermé (SOLID). La classe est donc ouverte pour ajouter une méthode de recherche similaire, comme par exemple FindByName, etc.

Mais FindByID est fermé et son implémentation est testée.

Je ne proposerai pas de méthodes avec prédicats, celles-ci sont bonnes au niveau générique. Et si basé sur le champ (ByID), vous avez une méthodologie complète différente.

Je suis surpris que personne n'ait suggéré d'utiliser un prédicat tel que celui-ci:

User Find(Predicate<User> predicate)

Avec cette approche, vous réduisez non seulement la surface de votre API, mais vous donnez également plus de contrôle à l'utilisateur qui l'utilise.

Si cela ne suffit pas, vous pouvez toujours l'étendre à vos besoins.