¿Es suficiente distinguir los métodos solo por el nombre del argumento (no el tipo)?

¿Es suficiente distinguir los métodos solo por el nombre del argumento (no el tipo) o es mejor nombrarlo más explícitamente?

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

¿Hay alguna buena razón para nombrarlo más explícitamente (es decir, agregar ById) en lugar de mantener solo el nombre del argumento?

Una razón por la que puedo pensar es cuando las firmas de los métodos son las mismas pero tienen un significado diferente.

FindByFirstName(string name) y FindByLastName(string name)

Claro que hay una buena razón para nombrarlo más explícitamente.

No es principalmente la definición del método la que debe explicarse por sí misma, sino el uso del método . Y mientras findById(string id)y find(string id)se explican por sí mismos, hay una gran diferencia entre findById("BOB")y find("BOB"). En el primer caso, usted sabe que el literal aleatorio es, de hecho, un Id. En el último caso, no está seguro: en realidad podría ser un nombre de pila o algo completamente diferente.

Ventajas de FindById () .

1. A prueba de futuro : si comenzar con Find(int), y luego tener que agregar otros métodos ( FindByName(string), FindByLegacyId(int), FindByCustomerId(int), FindByOrderId(int), etc), la gente como yo tienden a pasar las edades buscando FindById(int). No es realmente un problema si se puede y va a cambiar Find(int)a la FindById(int)vez que se hace necesario - el futuro es a prueba sobre estos si s.

2. Más fácil de leer . Findestá perfectamente bien si la llamada parece record = Find(customerId);Sin embargo, FindByIdes un poco más fácil de leer si lo es record = FindById(AFunction());.

3. La consistencia . Puede aplicar constantemente el patrón FindByX(int)/ en FindByY(int)todas partes, pero Find(int X)/ Find(int Y)no es posible porque entran en conflicto.

Ventajas de Find ()

• BESO. Findes simple y directo, y junto operator[]con uno de los 2 nombres de funciones más esperados en este contexto. (Algunas alternativas populares que son get, lookupo fetch, dependiendo del contexto).
• Como regla general, si tiene un nombre de función que es una sola palabra conocida que describe con precisión lo que hace la función, úsela. Incluso si hay un nombre de varias palabras más largo que es un poco mejor para describir lo que hace la función. Ejemplo: longitud frente a NumberOfElements . Hay una compensación, y dónde trazar la línea está sujeto a un debate en curso.
• En general, es bueno evitar la redundancia. Si observamos FindById(int id), podemos eliminar fácilmente la redundancia cambiándola a Find(int id), pero hay una compensación: perdemos algo de claridad.

Alternativamente, puede obtener las ventajas de ambos utilizando Ids fuertemente tipados:

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

Implementación de Id<>: Escribiendo valores de ID en C #

Los comentarios aquí, así como en el enlace anterior, plantearon múltiples preocupaciones con respecto a las Id<Customer>que me gustaría abordar:

• Preocupación 1: es un abuso de genéricos. CustomerIdy OrderIDson diferentes tipos ( customerId1 = customerId2;=> bueno, customerId1 = orderId1;=> malo), pero su implementación es casi idéntica, por lo que podemos implementarlos con copiar y pegar o con metaprogramación. Si bien hay un valor en una discusión sobre exponer u ocultar lo genérico, la metaprogramación es para qué sirven los genéricos.
• Preocupación 2: No detiene errores simples. Es una solución en busca de un problema. El problema principal que se elimina mediante el uso de identificadores fuertemente tipados es el orden de argumento incorrecto en una llamada a DoSomething(int customerId, int orderId, int productId). Los ID fuertemente tipados también evitan otros problemas, incluido el que se le preguntó a OP.
• Preocupación 3: realmente solo oscurece el código. Es difícil saber si se retiene una identificación int aVariable. Es fácil decir que se retiene un ID Id<Customer> aVariable, e incluso podemos decir que es un ID de cliente.
• Preocupación 4: estos ID no son tipos fuertes, solo envoltorios. Stringes solo una envoltura byte[]. La envoltura, o encapsulación, no está en conflicto con la tipificación fuerte.
• Preocupación 5: está sobre diseñado. Aquí está la versión mínima, aunque recomiendo agregar operator==y operator!=también, si no desea confiar exclusivamente en 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; }
}

Otra forma de pensar en esto es usar la seguridad de tipo del idioma.

Puede implementar un método como:

Find(FirstName name);

Donde FirstName es un objeto simple que envuelve una cadena que contiene el nombre y significa que no puede haber confusión en cuanto a lo que está haciendo el método, ni en los argumentos con los que se llama.

Voy a votar por una declaración explícita como FindByID ... El software debe ser creado para el cambio. Debe estar abierto y cerrado (SÓLIDO). Entonces, la clase está abierta para agregar un método de búsqueda similar como digamos FindByName ... etc.

Pero FindByID está cerrado y su implementación está probada por unidad.

No sugeriré métodos con predicados, esos son buenos a nivel genérico. ¿Qué sucede si en función del campo (ByID) tiene una metodología diferente?

Me sorprende que nadie sugiera usar un predicado como el siguiente:

User Find(Predicate<User> predicate)

Con este enfoque, no solo reduce la superficie de su API, sino que también le da más control al usuario que la usa.

Si eso no es suficiente, siempre puede ampliarlo a sus necesidades.