Достаточно ли того, чтобы методы отличались только по имени аргумента (не по типу)?

Достаточно ли, чтобы методы отличались только по имени аргумента (не по типу) или лучше назвать его более явно?

Так , например T Find<T>(int id)против T FindById<T>(int id).

Есть ли веская причина называть его более явно (т.е. добавлять ById) вместо сохранения только имени аргумента?

Я могу подумать об одной причине, когда сигнатуры методов одинаковы, но имеют разное значение.

FindByFirstName(string name) а также FindByLastName(string name)

Конечно, есть веская причина назвать это более явно.

Прежде всего, это не само определение метода , а само использование метода . И хотя findById(string id)и find(string id)оба говорят сами за себя, существует огромная разница между findById("BOB")и find("BOB"). В первом случае вы знаете, что случайный литерал фактически является идентификатором. В последнем случае вы не уверены - на самом деле это может быть имя или что-то другое.

Преимущества 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, в зависимости от контекста).
• Как правило, если у вас есть имя функции, представляющее собой одно хорошо известное слово, которое точно описывает, что делает функция, используйте его. Даже если есть более длинное имя, состоящее из нескольких слов, которое немного лучше описывает, что делает функция. Пример: Длина против NumberOfElements . Существует компромисс, и вопрос о том, где провести черту, является предметом постоянных дебатов.
• Как правило, хорошо избегать избыточности. Если мы посмотрим FindById(int id), мы можем легко удалить избыточность, изменив ее на Find(int id), но есть компромисс - мы теряем некоторую ясность.

В качестве альтернативы вы можете получить преимущества обоих , используя строго типизированные идентификаторы:

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

Реализация Id<>: строго вводить значения идентификаторов в C #

Комментарии здесь, а также в ссылке выше, вызвали многократные опасения относительно того, Id<Customer>что я хотел бы рассмотреть:

• Проблема 1: это злоупотребление дженериками. CustomerIdи OrderIDэто разные типы ( customerId1 = customerId2;=> хороший, customerId1 = orderId1;=> плохой), но их реализация почти идентична, поэтому мы можем реализовать их либо с помощью вставки копии, либо с помощью метапрограммирования. В то время как в обсуждении есть смысл показывать или скрывать универсальное, метапрограммирование - то, для чего предназначены универсальные.
• Проблема 2: Это не останавливает простые ошибки. Это решение в поисках проблемы . Главная проблема, которая устраняется с помощью строго типизированных идентификаторов, - это неправильный порядок аргументов в вызове DoSomething(int customerId, int orderId, int productId). Строго набранные идентификаторы также предотвращают другие проблемы, включая тот, о котором спрашивал ОП.
• Проблема 3: Это действительно просто затеняет код. Трудно сказать, если идентификатор удерживается int aVariable. Легко сказать, что идентификатор удерживается Id<Customer> aVariable, и мы можем даже сказать, что это идентификатор клиента.
• Проблема 4: Эти идентификаторы не являются сильными типами, это просто оболочки. 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 .... Программное обеспечение должно быть построено для изменения. Он должен быть открытым и закрытым (ТВЕРДЫМ). Таким образом, класс открыт для добавления аналогичного метода поиска, например, скажем FindByName .. и т. Д.

Но FindByID закрыт, и его реализация проверена модулем.

Я не буду предлагать методы с предикатами, они хороши на общем уровне. Что делать, если на основе поля (ByID) у вас есть совершенно другая методология.

Я удивлен, что никто не предложил использовать предикат, такой как следующее:

User Find(Predicate<User> predicate)

При таком подходе вы не только уменьшаете поверхность своего API, но и даете больше контроля пользователю, использующему его.

Если этого недостаточно, вы всегда можете расширить его для своих нужд.