É suficiente distinguir métodos apenas pelo nome do argumento (não pelo tipo)?

É suficiente distinguir métodos apenas pelo nome do argumento (não pelo tipo) ou é melhor nomeá-lo mais explicitamente?

Por exemplo T Find<T>(int id)vs T FindById<T>(int id).

Existe alguma boa razão para nomeá-lo de forma mais explícita (por exemplo, adicionar ById) vs manter apenas o nome do argumento?

Uma razão pela qual consigo pensar é quando as assinaturas dos métodos são iguais, mas têm um significado diferente.

FindByFirstName(string name) e FindByLastName(string name)

Certamente, há uma boa razão para nomeá-lo mais explicitamente.

Não é principalmente a definição do método que deve ser auto-explicativa, mas o uso do método . E embora findById(string id)e find(string id)sejam ambos auto-explicativos, há uma enorme diferença entre findById("BOB")e find("BOB"). No primeiro caso, você sabe que o literal aleatório é, de fato, um ID. No último caso, você não tem certeza - pode realmente ser um nome ou algo completamente diferente.

Vantagens de FindById () .

1. Futuro à prova : Se você começar com Find(int), e mais tarde tem que adicionar outros métodos ( FindByName(string), FindByLegacyId(int), FindByCustomerId(int), FindByOrderId(int), etc), pessoas como eu tendem a gastar idades procurando FindById(int). Não é realmente um problema se você puder e mudará Find(int)para FindById(int)quando necessário - a prova futura é sobre estes se s.

2. Mais fácil de ler . Findestá perfeitamente bem se a chamada parecer record = Find(customerId);Ainda FindByIdé um pouco mais fácil de ler se estiver record = FindById(AFunction());.

3. Consistência . Você pode aplicar consistentemente o padrão FindByX(int)/ em FindByY(int)qualquer lugar, mas Find(int X)/ Find(int Y)não é possível porque eles entram em conflito.

Vantagens de Find ()

• BEIJO. Findé simples e direto e, ao lado operator[]dele, é um dos 2 nomes de funções mais esperados nesse contexto. (Algumas alternativas populares sendo get, lookupoufetch , dependendo do contexto).
• Como regra geral, se você tiver um nome de função que seja uma única palavra conhecida que descreva com precisão o que a função faz, use-a. Mesmo se houver um nome mais longo com várias palavras, é um pouco melhor para descrever o que a função faz. Exemplo: Length vs NumberOfElements . Há uma troca, e onde traçar a linha está sujeito a um debate em andamento.
• Geralmente é bom evitar redundância. Se olharmos FindById(int id), podemos remover facilmente a redundância alterando-a para Find(int id), mas há uma troca - perdemos alguma clareza.

Como alternativa, você pode obter as vantagens de ambos usando IDs fortemente tipados:

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

Implementação de Id<>: Digitando fortemente valores de ID em C #

Os comentários aqui, bem como no link acima, levantaram várias preocupações sobre as Id<Customer>quais gostaria de abordar:

• Preocupação 1: É um abuso de genéricos. CustomerIde OrderIDsão tipos diferentes ( customerId1 = customerId2;=> bom, customerId1 = orderId1;=> ruim), mas sua implementação é quase idêntica, para que possamos implementá-los com copiar colar ou com metaprogramação. Embora exista valor em uma discussão sobre expor ou ocultar o genérico, a metaprogramação é para que servem os genéricos.
• Preocupação 2: não impede erros simples. / É uma solução em busca de um problema O principal problema que é removido usando Ids fortemente tipados é a ordem errada dos argumentos em uma chamada para DoSomething(int customerId, int orderId, int productId). Ids fortemente tipados também evitam outros problemas, incluindo o que o OP perguntou.
• Preocupação 3: Ele realmente apenas obscurece o código. É difícil dizer se um ID é mantido int aVariable. É fácil dizer que um ID está retido Id<Customer> aVariable, e podemos até dizer que é um ID de cliente.
• Preocupação 4: esses IDs não são tipos fortes, apenas invólucros. Stringé apenas um invólucro byte[]. O agrupamento ou encapsulamento não está em conflito com a digitação forte.
• Preocupação 5: acabou de engenharia. Aqui está a versão mínima, embora eu recomende adicionar operator==e operator!=também, se você não quiser confiar exclusivamente em 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; }
}

Outra maneira de pensar sobre isso é usar o tipo de segurança da linguagem.

Você pode implementar um método como:

Find(FirstName name);

Onde FirstName é um objeto simples que envolve uma string que contém o primeiro nome e significa que não pode haver confusão quanto ao que o método está fazendo, nem nos argumentos com os quais é chamado.

Vou votar em declarações explícitas como FindByID .... O software deve ser criado para o Change. Deve estar aberto e fechado (SOLID). Portanto, a classe está aberta para adicionar um método de localização semelhante, como, por exemplo, FindByName ... etc.

Mas FindByID está fechado e sua implementação é testada em unidade.

Não vou sugerir métodos com predicados, eles são bons em nível genérico. E se, com base no campo (ByID), você concluir uma metodologia diferente.

Estou surpreso que ninguém tenha sugerido usar um predicado como o seguinte:

User Find(Predicate<User> predicate)

Com essa abordagem, você não apenas reduz a superfície da sua API, mas também dá mais controle ao usuário que a usa.

Se isso não for suficiente, você sempre poderá expandi-lo para suas necessidades.