仅通过参数名称（而不是类型）来区分方法是否足够？

仅通过参数名称（而不是类型）来区分方法就足够了吗？还是更明确地命名呢？

例如T Find<T>(int id)VS T FindById<T>(int id)。

是否有充分的理由更明确地命名（即添加ById）而不是仅保留参数名称？

我能想到的一个原因是方法的签名相同但含义不同。

FindByFirstName(string name) 和 FindByLastName(string name)

当然，有充分的理由更明确地命名它。

应该不言而喻的主要不是方法定义，而是方法的使用。并且findById(string id)和find(string id)都是不言而喻的，findById("BOB")并且和之间存在巨大差异find("BOB")。在前一种情况下，您知道随机文字实际上是一个ID。在后一种情况下，您不确定-可能实际上是给定名称或完全是其他名称。

FindById（）的优点。

1. 面向未来：如果你下手Find(int)，后来有增加其他的方法（FindByName(string)，FindByLegacyId(int)，FindByCustomerId(int)，FindByOrderId(int)，等），我这样的人往往要花费年龄寻找 FindById(int)。如果您可以并且一旦有必要就将其更改Find(int)为不是真正的问题FindById(int)- 如果 s，则将来的证明就是这些。

2. 更容易阅读。Find是完全正常的，如果呼叫貌似record = Find(customerId);又FindById是读书，如果是稍微容易record = FindById(AFunction());。

3. 一致性。您可以在任何地方始终使用FindByX(int)/ FindByY(int)模式，但是Find(int X)/ Find(int Y)不可能，因为它们会发生冲突。

Find（）的优点

• 吻。Find非常简单明了，并且operator[]它是此上下文中2个最值得期待的函数名称之一。（根据上下文get，一些流行的替代方法是，lookup或fetch）。
• 根据经验，如果函数名称是一个众所周知的单词，可以准确地描述该函数的功能，请使用它。即使存在更长的多词名称，它在描述函数功能方面也会稍好一些。示例：长度 vs NumberOfElements。需要权衡取舍，如何划定界线仍在进行辩论。
• 通常最好避免冗余。如果看一下FindById(int id)，我们可以很容易地通过将其更改为来消除冗余Find(int id)，但是这是一个折衷方案-我们失去了一些清晰度。

另外，通过使用强类型Id，您可以同时获得两者的优点：

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

实现Id<>：在C＃中强键入ID值

此处以及上面的链接中的评论引起Id<Customer>了我要解决的多个问题：

• 关注点1：这是泛型的滥用。 CustomerId和OrderID是不同的类型（customerId1 = customerId2;=>好，customerId1 = orderId1;=>坏），但是它们的实现几乎相同，因此我们可以使用复制粘贴或元编程来实现它们。虽然在讨论中有关于暴露或隐藏泛型的价值，但是元编程是泛型的用途。
• 关注点2：这不会停止简单的错误/这是解决问题的解决方案通过使用强类型Id消除的主要问题是对的调用中的错误参数顺序DoSomething(int customerId, int orderId, int productId)。强类型的ID还可以防止其他问题，包括被问到的一个OP。
• 问题3：它实际上只是使代码模糊。很难确定ID是否保留在中int aVariable。容易知道ID保留在中Id<Customer> aVariable，我们甚至可以说这是客户ID。
• 问题4：这些ID不是强类型，只是包装器。 String只是一个包装byte[]。包装或封装与强类型没有冲突。
• 关注点5：设计过度。下面是最小的版本，虽然我不建议加operator==和operator!=为好，如果你不想完全依赖于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; }
}

考虑这种情况的另一种方法是使用语言的类型安全性。

您可以实现以下方法：

Find(FirstName name);

其中，FirstName是一个简单的对象，该对象包装了一个包含名字的字符串，这意味着该方法的作用以及调用该方法的参数都不会引起混淆。

我将投票支持像FindByID这样的显式声明。...应该为Change构建软件。它应该是打开和关闭（SOLID）。因此，该类是开放的，以添加类似的find方法，比如说FindByName ..等。

但是FindByID已关闭，其实现已进行了单元测试。

我不会建议使用谓词的方法，这些方法在通用级别上很不错。如果基于字段（ByID），您有完全不同的方法该怎么办。

我很惊讶没有人建议使用以下谓词：

User Find(Predicate<User> predicate)

使用这种方法，不仅可以减少API的表面，而且可以使使用它的用户获得更多控制权。

如果这还不够，您可以随时根据需要进行扩展。