È sufficiente distinguere i metodi solo per nome dell'argomento (non per tipo)?

È sufficiente che i metodi siano distinti solo dal nome dell'argomento (non dal tipo) o è meglio denominarlo in modo più esplicito?

Per esempio T Find<T>(int id)vs T FindById<T>(int id).

C'è qualche buona ragione per nominarlo in modo più esplicito (cioè aggiungendo ById) vs mantenendo solo il nome dell'argomento?

Una delle ragioni a cui riesco a pensare è quando le firme dei metodi sono uguali ma hanno un significato diverso.

FindByFirstName(string name) e FindByLastName(string name)

Sicuramente c'è una buona ragione per nominarlo in modo più esplicito.

Non è principalmente la definizione del metodo che dovrebbe essere autoesplicativa, ma l' uso del metodo . E mentre findById(string id)e find(string id)sono entrambi auto-esplicativo, v'è una grande differenza tra findById("BOB")e find("BOB"). Nel primo caso sai che il letterale casuale è, in effetti, un ID. In quest'ultimo caso non sei sicuro - potrebbe effettivamente essere un determinato nome o qualcos'altro del tutto.

Vantaggi di FindById () .

1. A prova di futuro : se si inizia con Find(int), e poi devono aggiungere altri metodi ( FindByName(string), FindByLegacyId(int), FindByCustomerId(int), FindByOrderId(int), ecc), le persone come me tendono a spendere le età in cerca di FindById(int). Non è un problema se si può e cambierà Find(int)per FindById(int)una volta si rende necessario - futuro proofing è su queste se s.

2. Più facile da leggere . Findva benissimo se la chiamata sembra record = Find(customerId);Eppure FindByIdè leggermente più facile da leggere se lo è record = FindById(AFunction());.

3. Coerenza . È possibile applicare coerentemente il FindByX(int)/ FindByY(int)pattern ovunque, ma Find(int X)/ Find(int Y)non è possibile perché sono in conflitto.

Vantaggi di Find ()

• BACIO. Findè semplice e diretto e accanto operator[]è uno dei 2 nomi di funzioni più attesi in questo contesto. (Alcune alternative popolari di essere get, lookupo fetch, a seconda del contesto).
• Come regola generale, se si dispone di un nome di funzione che è una singola parola ben nota che descrive accuratamente ciò che la funzione fa, usarla. Anche se esiste un nome a più parole più lungo che è leggermente migliore nel descrivere ciò che fa la funzione. Esempio: lunghezza vs NumberOfElements . C'è un compromesso e dove tracciare la linea è oggetto di un dibattito in corso.
• È generalmente buono evitare la ridondanza. Se guardiamo FindById(int id), possiamo facilmente rimuovere la ridondanza cambiandola in Find(int id), ma c'è un compromesso: perdiamo un po 'di chiarezza.

In alternativa puoi ottenere i vantaggi di entrambi usando ID fortemente tipizzati:

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

Implementazione di Id<>: valori ID fortemente digitati in C #

I commenti qui, così come nel link sopra, hanno sollevato molteplici preoccupazioni riguardo a Id<Customer>ciò che vorrei affrontare:

• Preoccupazione 1: è un abuso di generici. CustomerIde OrderIDsono tipi diversi ( customerId1 = customerId2;=> buono, customerId1 = orderId1;=> cattivo), ma la loro implementazione è quasi identica, quindi possiamo implementarli con copia incolla o con metaprogrammazione. Mentre in una discussione c'è valore sull'esporre o nascondere il generico, la metaprogrammazione è ciò a cui servono i generici.
• Preoccupazione 2: non impedisce errori semplici. / È una soluzione alla ricerca di un problema. Il problema principale che viene rimosso utilizzando ID fortemente tipizzati è l'ordine degli argomenti errato in una chiamata a DoSomething(int customerId, int orderId, int productId). Gli ID fortemente tipizzati impediscono anche altri problemi, incluso quello richiesto.
• Preoccupazione 3: oscura davvero il codice. È difficile dire se un ID è trattenuto int aVariable. È facile dire che un ID è conservato Id<Customer> aVariablee possiamo persino dire che è un ID cliente.
• Preoccupazione 4: questi ID non sono tipi forti, ma solo wrapper. Stringè solo un involucro in giro byte[]. Il wrapping o l'incapsulamento non è in conflitto con la tipizzazione forte.
• Preoccupazione 5: è troppo ingegnerizzato. Ecco la versione minima, anche se ti consiglio di aggiungere operator==e operator!=, se non vuoi affidarti esclusivamente a 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; }
}

Un altro modo di pensare a questo è usare la sicurezza del tipo della lingua.

È possibile implementare un metodo come:

Find(FirstName name);

Dove FirstName è un oggetto semplice che avvolge una stringa che contiene il nome e significa che non può esserci confusione su ciò che sta facendo il metodo, né sugli argomenti con cui viene chiamato.

Voterò per una dichiarazione esplicita come FindByID .... Il software dovrebbe essere creato per il cambiamento. Dovrebbe essere aperto e chiuso (SOLIDO). Quindi la classe è aperta per aggiungere un metodo di ricerca simile come diciamo FindByName ... ecc.

Ma FindByID è chiuso e la sua implementazione è testata dall'unità.

Non suggerirò metodi con predicati, quelli sono buoni a livello generico. Che cosa succede se in base al campo (ByID) hai una metodologia diversa completa.

Sono sorpreso che nessuno abbia suggerito di usare un predicato come il seguente:

User Find(Predicate<User> predicate)

Con questo approccio non solo riduci la superficie dell'API ma dai anche più controllo all'utente che la utilizza.

Se ciò non bastasse, puoi sempre espanderlo alle tue esigenze.